icyfox

I bought a Sony TRV120 10+ years ago, back when I was doing this conversion project for the first time. It's built like a tank and still works today.

At the risk of being smited by professional archivists, I'm willing to wager that 99.9% of people can't tell the difference between a $5k archival rig and one of these higher quality camcorders. At this point it really feels like the biggest inhibiter to good quality digitization is the decaying of the tape versus the archival setup.

That said - for anyone with the time, patience, and soldering abilities I would love a more proper A/B test with RF signal capture software encoding. Something like this:

https://rastrillo.ca/digitizing-video8-tapes-with-vhs-decode...

Since the webapp is pretty opinionated to my setup (ie. linking against AVFoundation, using MPS for inference, always capturing an image after import) I didn't originally think it would be that useful to open source. Happy to do so - are you looking to get something specific out of it?

Most of my tapes did have pretty detailed narration and date overlays written directly to tape. But even without narration I still had luck doing basic event summarization and facial recognition of family members to build the tags.

Yes - garbage in / garbage out still holds true for most things when it comes to LLM training.

The two bits about this paper that I think are worth calling out specifically:

- A reasonable amount of post-training can't save you when your pretraining comes from a bad pipeline; ie. even if the syntactics of the input pretrained data are legitimate it has learned some bad implicit behavior (thought skipping)

- Trying to classify "bad data" is itself a nontrivial problem. Here the heuristic approach of engagement actually proved more reliable than an LLM classification of the content

It's a neat chip but I couldn't bring myself to spend in excess of the price of the UPS ($439.00 for RMCARD at time of writing). I ended up hooking my UPS via USB to my existing home server via NUT and it's been working well.

All of the products you mention already had research teams (in the case of ChatGPT and Claude that actually predated most of their engineers). So knowing how to build small language models was always in their wheel house. Scaling up to larger LLMs required a few algorithmic advancements but for the most part it was a question of sourcing more data and more compute. The remarkable part of transformers is their scaling laws, which let us achieve much better models without having to reinvent new architecture.

The folks at deno have really done a fantastic job at pushing a JS runtime forward in a way that's more easily plug and play for the community. I've used `denoland/deno_core` and `denoland/rusty_v8` quite a bit in embedded projects where I need full JS support but I can't assume users have node/bun/etc installed locally.

Not surprised to see yt-dlp make a similar choice.

From the jump, even without the emdashes, it was crystal clear that this post was written by Claude. I'm sure the OP put their own ideas into the prompt, provided some sources, etc. But reading some of these phrases provoked a pretty visceral sense that I'm just reading an LLM's output:

"The harsh reality" "he perfectly captured" "architectural decisions that make senior engineers weep" "fundamental issue"

It makes me wonder whether a whole class of writing is going to be deprecated because the cadence is just too similar to LLM outputs.

I'm responding to the parent comment who's suggesting we version control the "model" in Docker. There are infra reasons why companies don't do that. Numerical instability is one class of inference issues, but there can be other bugs in the stack separate from them intentionally changing the weights or switching to a quantized model.

As for the original forum post:

- Multiple numerical computation bugs can compound to make things worse (we saw this in the latest Anthropic post-mortum)

- OP didn't provide any details on eval methodology, so I don't think it's worth speculating on this anecdotal report until we see more data

I guarantee you the weights are already versioned like you're describing. Each training run results in a static bundle of outputs and these are very much pinned (OpenAI has confirmed multiple times that they don't change the model weights once they issue a public release).

> Not quantized. Weights are the same. If we did change the model, we’d release it as a new model with a new name in the API.”

- [Ted Sanders](https://news.ycombinator.com/item?id=44242198) (OpenAI)

The problem here is that most issues stem from broader infrastructure issues like numerical instability at inference time. Since this affects their whole service pipeline, the logic here can't really be encapsulated in a frozen environment like a Docker container. I suppose _technically_ they could maintain a separate inference cluster for each of their point releases, but that also means that previous models don't benefit from common infrastructure improvements / load balancing would be more difficult to shard across GPUs / might be logistically so hard to coordinate to effectively make it impossible.

https://www.anthropic.com/engineering/a-postmortem-of-three-... https://thinkingmachines.ai/blog/defeating-nondeterminism-in...

Good for Namecheap. They're still my default when I'm searching for new domains, even though I end up registering somewhere else (their bulk search is still best in class imo).

I'm a bit surprised at their revenue numbers considering domain registration is pretty much a commodity at this point. I always assumed non-technical people would first go to a web host/email provider that lets them buy a domain vs. a domain registrar that also supports email and web hosting. Clearly I'd be wrong.

Some text diffusion models use continuous latent space but they historically haven't done that well. Most the ones we're seeing now typically are trained to predict actual token output that's fed forward into the next time series. The diffusion property comes from their ability to modify previous timesteps to converge on the final output.

I have an explanation about one of these recent architectures that seems similar to what Mercury is doing under the hood here: https://pierce.dev/notes/how-text-diffusion-works/

Definitely some similarities!

SQLModel is also based on Pydantic, so the schema definitions that you'll write will look very similar to Iceaxe. Internally however SQLModel is implemented as a wrapper over SQLAlchemy. This is beneficial for support of multiple different database backends (mysql+postgres+sqlite) and for its battle tested track record. But as a drawback it also inherits a lot of the SQLAlchemy baggage like async+sync incompatibility and some funkiness with passing through types.

Since Iceaxe just targets Postgres, it can simplify a lot of those assumptions. It's implemented as async-only, leverages the most recent additions to typehinting in Python 3.12, and bakes in migration support. Documentation can capture explicit best practices for targeting Postgres versus attempting to abstract across every database backend.

It's also a bit different philosophically. It encourages explicit sql when you need to write complex queries; we support programatic joins out-of-the-box, but for more complex SQL (common table expressions for one) I find an ORM can often overly abstract what your engine is actually doing and hide subtle bugs that make their way into production.

I've spent quite some time with SQLModel as part of my Mountaineer web framework. It's great - just targets a broader range of ORM goals. Philosophically I'm trying to keep Iceaxe lean, fast, and Postgres optimized.

I imagine a lot of this comes down to personal preference. In the early days of Mountaineer [^1] (gee, almost two months ago at this point), I played around with the idea of embedding html into python instead of needing a JS layer. Eventually my consensus was:

- The most flexible shim approaches typically end up wrapping JS/React components anyway (like Reflex/Pinecone)

- We really need better IDE support for html strings that are within python strings. The editing problem is a big setback.

The ergonomics of Python + JS in separate code files won out and the user experience has been better than forcing them both into a common language would be.

This has the benefit of leveraging whatever the two languages are best at, in native code, so you have access to all the native APIs without having to learn a shim on top of it. Way more longevity to that approach too. Context switching between two languages isn't that bad if you minimize the glue layer that you have to write between them.

[^1]: https://github.com/piercefreeman/mountaineer

To be clear, I'm not saying we can't have this skilled workforce. Merely that we don't have it today. So the pipeline to employ Americans for these jobs is going to require increasing the funnel of people who learn the skills, become junior engineers, learn more on the job, then become senior engineers. That's a long pipeline to beef up the numbers.

The text of the bill [^1] disagrees with this:

> In awarding financial assistance for planning or establishing a Manufacturing USA Institute, an agency shall give special consideration to such institutes that

> contribute to the geographic diversity of the Manufacturing USA program,

> are located in an area with a low per capita income,

> are located in an area with a high proportion of socially disadvantaged residents, or

> are located in small and rural communities.

It seems very much to be both.

[^1]: https://www.congress.gov/bill/117th-congress/house-bill/4346

Right now one of the biggest blockers in on-shoring semiconductor fab at any kind of reasonable price-point and timescale is the lack of a skilled workforce. This legislation has dual objectives: train new people to get into sophisticated manufacturing AND to build out the actual infrastructure itself. That almost guarantees it won't be the most efficient way to actually get these chips on American soil. Whether we look back in 20 years and think "wow glad we took that hit upfront" is anyone's guess.

Big proponent of guaranteed outputs for LLMs. I wrote a library awhile back (gpt-json) that did something similar by querying the OpenAI API. At the end of the day though while their responses are _highly likely_ to be valid JSON they're not guaranteed. There's only so much that can be done with remote calls to their model's black box.

The future here really lies in compiling down context free grammars. They let you model json, yml, csv, and other programming languages as finite state machines that can force LLM transitions. They end up being pretty magical: you can force value typing, enums, and syntax validation of multivariate payloads. For use in data pipelines they can't be beat.

I did some experiments a few weeks ago on training models to generate these formats explicitly with jsonformers/outlines. Finetuning in the right format is still important to maximize output. You can end up seeing a 7% lift if you finetune explicitly for your desired format. [^1] At inference time the CFGs will constrain your model to do what it's actually intended to.

[^1]: https://freeman.vc/notes/constraining-llm-outputs

When I took the GRE in 2017, everything was digital as well. But I couldn't believe how locked down the experience was. The testing center in downtown SF had no windows, a metal detector, and you had to check all food outside of the testing room. Just in case you were going to try to cheat off of your banana. I think each computer was also recording a video of you taking the test although I might be mistaken here. Certainly there were cameras set up all around the perimeter.

I'm shocked at how laissez-faire we've gotten for college entrance exams, which I'd arguably say are much more important at getting you _into_ the graduate programs than the actual graduate program exams are themselves.

Authentication and authorization is pretty easy to implement with custom Dependencies. Multitenancy can be a layer on top of that depending on how you want to shard your DB tables / separate rows. If you're interested in poking around a little more with auth then this plugin can be a starting place: https://github.com/piercefreeman/mountaineer/tree/1d44cdf1c6...

(In an old commit and stripped out from the current codebase until it has better test coverage and the main codebase is stable)

Thanks for the note! SecretStr is a good call as well. I'll switch to using that for the database layer. Also removed DS_Store in the latest PR (really thought I had ignored globally but they snuck in anyway).

Thanks for the kind words, yoz. I think it's easier to write documentation when you're actively using + codeveloping solutions using the library as well. The README guides are as much for my future self as they are for anyone else. :) If you end up poking around with it, please shoot me a line for anything that can use some additional coverage.

Yes it does! SSR support out of the box (powered by V8). This was one element of the Rust layer that was really important to pin down early and start benchmarking for performance. It ended up in a pretty nice place for the time-being: exception logging within the console and development frontend, 10-20ms rendering on average.

Hey buremba, can you share more about the use-case that you're thinking about? Like JS function calling within Python?

Hey giancarlostoro, big fan of OOP as well. I structured Controllers to just be regular classes - so you should be able to write server code and routes very similar to CherryPy.

I know this is what most of the SpaceX mission control systems do. They're set up with ~3x/5x redundancy for effectively consumer hardware. If they detect memory misalignment between 1/3 of the nodes, they'll power cycle it while the other 2 take primary control. Big cost savings by not having to purchase radiation-hardened hardware and AFAIK they see similar reliability.

A friend of mine created a bot to do basically this, except it also looks at the current page rank associated with researchers recommending that paper. I've seen a lot of good looking papers (decent school/group/conference submission/etc.) that don't end up contributing to the field. Top researchers and Professors tend to have a better intuition of importance by reading the abstract and a quick skim.

Just for connecting to an existing service: https://github.com/ollama/ollama-python/blob/main/ollama/_cl...

Well, Lora works just because it's a low rank approximation of full updates - much in the same way that SVD works, and regular gradient updating works. It delivers good results by both acting as a regularizer and by allowing larger models to be updated with smaller memory footprints.

My point is that the original Lora paper choosing the last layer is one choice. And it is likely the most common one because of its higher symbolic nature typically being all that's needed for good performance on downstream tasks.

Depending on the size of your finetuning job I've personally seen updating more layers (or updating some only on a certain learning rate schedule) to be more effective. Lora is just the mathematical technique of updating, it doesn't really have a hypothesis on the ideal training regimen.

Like most things in ML, the answer of which layers to use come down to empirical evidence more than theory. In a typical Lora training pipeline, you freeze the contents of the base model and just adjust the Lora layers. The more layers you convert to lora layers the more degrees of freedom you have for the optimization.

There are some finetuning regimens that only recommend finetuning the last layer since this is theorized to have the "highest order" representation of the inputs. Other training regimens will finetune all layers. It's largely data and problem dependent. Lora just mirrors this convention.