sethhochberg

We're just using Github Copilot as our primary entrypoint for all of the model families. Its the only way we can easily offer our devs some level of Claude, Gemini, and Codex all in one place.

I always find the idea that there's something to navigate kind of curious - as you say, its lots of managed versions of open source tools and a mix of proprietary management frameworks on top. Some of what they offer are genuinely unique products for niche use cases, but if you have that niche you probably know what services can support it, like the people in the other comments here mentioning the IoT APIs.

But me (or my teams) are rarely asking the question of "how should I run my service on AWS" in general, its much more typically "I need a managed Postgres database, what AWS product offers that" or "I have an OCI image, what managed platform can I run that in" or even "I want this endpoint to be available all the time, but its usage is very unpredictable/intermittent, so I don't want to pay for idle compute". There might still be a couple of possible answers for those questions, but by the point I arrive there I'm solving for a specific problem.

Its sort of like walking into a kitchen hungry and seeing 3 knives and a stove and oven and a dozen peelers and can openers etc etc and being very overwhelmed by all of this (do I need the knife with a smooth edge or the serrated one?) until you decide you want to eat a grilled cheese, and then grabbing a skillet to put onto a burner and everything making sense once you actually start to cook a specific thing.

They're quite popular for distributed audio systems in general (of which sound masking is one type). "Constant voltage audio" comes in a few flavors and 70v is very common in the US, other parts of the world often use 100v. Background music systems in retail, voice paging systems, etc use constant voltage hardware because its much better technology for very long cable runs, daisy-chained speakers, and centrally located amplifiers.

The cost is fidelity. Full-range audio transformers aren't cheap, so these systems usually make some compromises because your announcements or smooth jazz over the pasta aisle don't need to be true hi-fi.

Its cool technology. Most of the speakers have variable power taps, so you can run a bunch of them in parallel on a single line and control the actual volume as-needed based on where the speaker is deployed by varying the transformer tap on each speaker.

I know this is written to be tounge-in-cheek, but its really almost the exact same problem playing out on both sides.

LLMs hallucinate because training on source material is a lossy process and bigger, heavier LLM-integrated systems that can research and cite primary sources are slow and expensive so few people use those techniques by default. Lowest time to a good enough response is the primary metric.

Journalists oversimplify and fail to ask followup questions because while they can research and cite primary sources, its slow and expensive in an infinitesimally short news cycle so nobody does that by default. Whoever publishes something that someone will click on first gets the ad impressions so thats the primary metric.

In either case, we've got pretty decent tools and techniques for better accuracy and education - whether via humans or LLMs and co - but most people, most of the time don't value them.

I think many people would suggest that this was more of an accident due to the ubiquity of the browser, though.

The transition from "websites" to "web apps" was well underway by the time the dev tools became a built-in browser feature - Chrome was notable for being the first browser to release with the console, inspectors, etc out of the box, but that came later. The developer experience was quite a bit rougher in the early days, and then better but still not native in the days of plugins like Firebug.

The web becoming the premium app distribution platform was, firstly, because the web was the lowest-common-denominator distribution channel. Javascript was just the tool that was available where everyone wanted to run.

In the US, there's often a large labor/materials upcharge on anything that can be branded as "green" - you see a lot of the same thing with higher end heat pump systems and such, too. Efficiency is (for whatever reasons) frequently sold as a luxury product feature in our market and the installers take advantage.

The evolutionary force is really just "everyone else showed up at the party". The Internet has gone from a capital-I thing that was hard to access, to a little-i internet that was easier to access and well known but still largely distinct from the real world, to now... just the real world in virtual form. Internet morality mirrors real world morality.

For the most part, everybody is participating now, and that brings all of the challenges of any other space with everyone's competing interests colliding - but fewer established systems of governance.

I don't know if they're available in other markets, but in the US I've been very happy with Lutron Caseta switches for that sort of "smart enough" use case. It generally all works like normal dumb switches if the hub is offline or doesn't exist, and you only need the hub to manage configuration or enable the remote control (outside home) features. The fact that the switches look like, act like, and install like traditional dimmers and control traditional light fixtures is really what sold me: I've never liked the idea of the smart parts being in something like a light bulb thats basically a replaceable wear item.

In our case, the files being processed are datasets that have already been normalized through another ETL tool. Since we're doing the preprocessing ourselves elsewhere, our Gleam parsers are set up to expect a pretty rigid set of inputs. We do all of the file IO / streaming in Elixir and pass the raw data into Gleam as Elixir maps: so Gleam just takes maps, parses them into types pretty rigidly, and our entire Gleam module ecosystem assumes "perfect enough" data.

If we encounter row-level errors in a batch, we log those alongside the outputs. There's nothing particularly intrinsic about out usage of Gleam that prevents the workers from crashing during processing, its all about having error handling set up within the job itself to avoid killing the process or pod running it.

I'm leading a team that is doing an incremental migration to Gleam by delegating specific parts - we're basically pushing the "functional core, imperative shell" pattern to its macro extreme and having Gleam pick up background jobs from our existing Ruby on Rails codebases where we have heavy calculation tasks.

This approach is notably not making proper or really any use of OTP features, but it was an extremely easy way to adopt a safe, fast, functional language for number-crunching workflows while continuing to lean on Rails for everything else its great at: web interfaces, HTTP APIs, etc.

Rails is basically the configuration tool for the various inputs of a job, and job is passed to Gleam via Redis as an atomic set of config inputs to be used when processing a dataset (usually big CSV files streamed from object storage). We use a very thin Elixir wrapper to do all network and file IO etc, Gleam modules are pure business logic called from Elixir.

Some day soon, I'm going to try and write up a longer technical article about this approach... it comes up surprisingly often in HN conversations.

One of my previous employers only lost our east-coast colo facility twice in their couple decades of existence:

- once when the DC ran out of diesel and couldn't get any more after Hurricane Sandy

- once when the backup generators caught fire and the fire department needed to kill grid power to the facility

Everything else is pretty reliable or easier to decouple from the local real world

I think you've actually buried a much broader commentary on tolerances and complexity and interoperability in here, too.

The mechanical-averaging voltage regulator worked for the design because it only had to work in the context of the specific model of car it was going into. It didn't have to produce 5v for any application that needs 5v; it just had to produce "5v" for the instruments in the '72 Dodge Challenger. That makes it a pretty terrible 5v regulator, but a pretty great part for the system it was designed to fit into if the mechanical-averaging version is more reliable or cheaper or more robust than the fancy electronic versions.

But if I'm designing a 5v regulator to be sold as a 5v regulator, well... I don't know what system its getting installed into so I won't have much luck selling one that, over a long enough time span, averages out to supplying 5v of power when its supplying power. So I have to design in tight tolerances, and everyone integrating my regulator has to design for tight tolerances, etc.

The good news is that now anyone can buy my regulator and get a reliable 5v - interchangeable parts! But the bad news is now every system on both sides has additional complexity for the sake of complying with our standard.

We see this _all the time_ in software, especially comparing old software to new. Why is Roller Coaster Tycoon so much more elegant and efficient than a modern game written on Unity? Sure, good tastes probably factor in - but that taste from the author was allowed to shine because it was designed as a complete system, not a bunch of component subsystems from different teams and vendors stitched together.

Honestly, I just type out something by hand that is roughly like what I quoted above - I'm not big on keeping prompt libraries.

I think the important part is to give it (in my case, these days "it" is gpt-5-codex) a target persona, just like giving it a specific problem instead of asking it to be clever or creative. I've never asked it for a summary of a long conversation without the context of why I want the summary and who the intended audience is, but I have to imagine that helps it frame its output.

I've had great luck with asking the current session to "summarize our goals, conversation, and other relevant details like git commits to this point in a compact but technically precise way that lets a new LLM pick up where we're leaving off".

The new session throws away whatever behind-the-scenes context was causing problems, but the prepared prompt gets the new session up and running more quickly especially if picking up in the middle of a piece of work that's already in progress.

What would you propose as an alternative?

As a corporate purchaser, "bring your own key" is just about the only way we can allow our employees to stay close to the latest happenings in a rapidly moving corner of the industry.

We need to have a decent amount of trust in the model execution environment and we don't like having tons of variable-cost subscriptions. We have that trust in our corporate-managed OpenAI tenant and have good governance and budget controls there, so BYOK lets us have flexibility to put different frontends in front of our trusted execution environment for different use cases.

10 years ago, I hated the idea of Google Glass, voice assistants, cloud doorbells, and their ilk. I thought the privacy zealots were reactionary but the general premise still was a bit icky - a little bit for the privacy, but mostly for the "weird nerd stuff" stigma.

5 years ago, I acquiesced started to let voice assistants into my home, thought the first edition of Meta Ray Bans were cool but not for me, and generally started to feel like these things were everywhere and nothing bad had come of it.

In the current year, I've gotten rid of all of my voice assistants, carefully blocked internet traffic for my IoT things, got rid of devices without local controllers, and would generally decline to be around someone who was wearing smart-camera glasses of any kind in the same way I'd decline to be around someone who was holding their phone up taking a video of me. The privacy zealots were right, it took some time - but we've learned that tech often isn't our benign anonymous friend. All it took was "tech" (the brand) completing its transition from benevolent cool hip industry to big business just like any other.

I'm currently working on a prototype that does exactly this (in our case, the Gleam is essentially a typed calculation module wrapped in Elixir's great libraries for network and database interactions but its all net-new application instead of an existing Elixir codebase). Its not yet perfect, but I've been eagerly following along with this PR: https://github.com/elixir-lang/elixir/pull/14262#issuecommen...

Seems like (one of) the next Elixir releases will include the support you're looking for in mix.

This was my first thought. My iPhone 15 Pro is fine and hopefully has much more life left in it, and I've gotten used to the size in general over the years, but I like to wear pants that are reasonably fitted and the "pocket bulge" outline of the phone still annoys me if I'm trying to deliberately look nice.

I'd believe this is an area where even a few millimeters of thickness makes a real difference in how much the phone in pocket stands out despite the overall footprint being larger? Will be curious to read once people get their hands on the things.

Years ago when I worked in live audio we had a similar setup. Zero tolerance for a performer's mic pack dying mid show because a low battery indicator wasn't calibrated right or someone incorrectly tracked how many hours a particular set had been used, so it was fresh-from-the-package alkaline AAs installed before every set, and a virtually unlimited supply of half-charged disposables to take home afterwards. Plenty would get reused for internal equipment checks and sound checks, but there were still more than enough to go around.

At the time (well over a decade ago) there was still lots of skepticism around recharagables and the extra process involved in dealing with them... but the tech has gotten lots better since, at that time even low-self-discharge was sort of hard to find. I'm sure much of the industry has moved over by now.

Typically with this sort of thing the way it really works is that you, the startup, use a service provider (like OpenAI) who publish their own external audit reports (like a SOC 2 Type 2) and then the SOC 2 auditors will see that the service provider company has a policy related to how it handles customer data for customers covered by Agreement XYZ, and require evidence to prove that the service provider company is following its policies related to not using that data for undeclared purposes or whatever else.

Audit rights are all about who has the most power in a given situation. Just like very few customers are big enough to go to AWS and say "let us audit you", you're not going to get that right with a vendor like Anthropic or OpenAI unless you're certifiably huge, and even then it will come with lots of caveats. Instead, you trust the audit results they publish and implicitly are trusting the auditors they hire.

Whether that is sufficient level of trust is really up to the customer buying the service. There's a reason many companies sell on-prem hosted solutions or even support airgapped deployments, because no level of external trust is quite enough. But for many other companies and industries, some level of trust in a reputable auditor is acceptable.

Frankly I think a lot of full-time-employed technical people are largely experimenting for fun in the context of things that might eventually be useful to their employer. AI is cool and fascinating stuff and when I have a few idle minutes at the end of my workweek I love catching up and experimenting with the latest and greatest, but with an eye towards company problems and on company time, and sometimes using company datasets. That means company vendor approval and financing of my efforts.

In my personal life, when its time for fun, I close the laptop and go do some gardening.

If all of the trades were there on the same day and each could begin their work immediately after the prior specialist had finished it might have taken a day or a few, but it sounds like much of that month was simply waiting. If you're handy and in a part of the world where you can just do all of this work yourself at your own pace its no surprise you can be much faster.

NYC is a famously difficult place to have work like this done, especially in a shared-ownership building like a condo. You need your neighbors to agree its okay to do, your board/management company needs to review and be satisfied with the insurance your contractors carry, the city has requirements for electrical that always require permits and often require a master electrician to do the work, and even once the work starts the walls and spaces you're working in aren't exclusively yours and your contractors will be discovering things along the way... plumbing for that spigot you didn't know your neighbor had on their terrace, roof drains, etc.

The process of just getting approval to do work can vary from "chill but time consuming" in small buildings to "impenetrable bureaucracy so don't bother if you're not using the approved vendors" in large co-ops. Once it starts, that master electrician you hired to run the 220v service isn't gonna waste his time repairing drywall, a cheaper subcontractor will do that, and the latency just cranks up from there

I love city living and understand that most of these rules and regulations exist because bad things happened when they didn't - frankly I wouldn't trust most of my neighbors in buildings I've lived in to do their own electrical work or pierce the building's envelope for any reason - but also sort of understand where the outsider's perception that city homeowner life is hard and expensive comes from. It very often is, by comparison.

Some less-common varieties of life insurance start to look a whole lot like investment products and are (sometimes controversially) sold as such for people in very specific financial situations - think like cash value and death benefit value that vary over time based on asset performance. A legacy insurer selling Variable Universal Life or similar policies would have some financial calculation needs.

With term life insurance specifically the lifetime policy premiums are typically so low relative to the value of the policy that there's a natural bias towards insuring generally healthy people. Its not uncommon to see policies that are something like $40/month for 20 years ($9600 in premiums) for a $1mm death benefit, for example.

People with more complex medical conditions often can get life insurance from smaller, specialized providers... and at much higher rates. But the big mass-market players offering inexpensive term life products are only offering them that cheaply because they really control the risk profile during underwriting.

The part I have a hard time with as a corporate purchaser is that the failure/repair/replacement rate on our small number of Dell machines is upwards of 50%. We've only got about a dozen in use, and less then half of them have just worked reliably. At a certain point I don't really care how repairable the Macbooks we buy for almost everyone else are/aren't because the failure rate on those is so low by comparison.

I'm glad the Dell repair guy who gets sent out has a pleasant experience when he replaces the guts of a machine but my team still has to spend time and money shipping around replacements and dealing with warranty repair at a rate we just don't see with the Apple gear.

Once upon a time our entire corporate fleet was all Macbooks but the only thing we had worse luck with than these Dells was training nontechnical users on how to get to their Excel or specialized actuarial/compliance software through virtualization

When you work with Apex (or really any other technology bridge to the traditional financial world, Q2's Helix is common for traditional banking, Apex Clearing is common for stock trading, etc) they require you think about things like this during your implementation. Its not quite as turnkey as something like opening a Stripe account; your implementation will need to demonstrably pass a playbook of tests before your partner will allow you to play in real financial transactions - and those tests typically include things like account closure or program shutdown.

Basically, the traditional financial services partners who give startups access to these legacy networks know their clients are startups who might not fully understand the space or might want to cut corners. They're good at making sure they're protected against their clients' behavior, and in most cases legally the end users are actually the customer of the financial services company, the startup will be considered a "deposit broker" instead of a "bank" etc. Its been longer since I've touched the stock broker side so I'm fuzzy on the specific terminology but its similar there.

Regrettably the only source I can find hosting this video is a reddit post, but you might find the remarks by the MTA chair interesting: https://www.reddit.com/r/nycrail/comments/1iyve4d/mta_buildi...

In short: for decades they’ve been allergic to doing any design or project management in house, which meant brand new teams of consultants and contractors spun up for every single project. Lucrative for the consultants, not an efficient way to use funds for a big organization that is constantly doing design and construction.

Seems like the MTA is finally starting to invest in building internal expertise again so they can stop farming everything out

You’re asking a fair question but I think you’re approaching it from a POV that’s maybe a bit more of an engineering mindset than the person you’re responding to is using

A brilliant algorithm that filters out some huge amount of AI slop is still frustrating to the user if any highly ranked AI slop remains. You still click it, immediately notice what it is, and wonder why the algo couldn’t figure this out if you did so quickly

It’s like complaining to a waiter that there’s a fly in your soup, and the waiter can’t understand why you’re upset because there were many more flies in the soup before they brought it to the table and they managed to remove almost all of them

"Healthy" is a pretty loaded word. In the grand scheme of things apples and peanut butter is indeed a pretty healthy snack: good balance of fiber and protein and carbs and healthy fats, and nothing particularly bad like partially hydrogenated oils if you stick to a decent brand of peanut butter. But its not a particularly low-anything snack, so maybe not an efficient use of calories for someone trying to watch their weight. Nuts in general are a pretty caloric food.

Occasionally (usually as a distraction while trying to make a meal plan for the week) I find myself wondering by what we could do differently with the concept of healthy foods that makes nuances like this easier for people to understand, without getting into fad diet territory. I've never had a brilliant idea here because its fundamentally asking the public to have a nuanced understanding in an industry with tons of historical marketing spin, which is... hard. Really hard. Fad diets and diet plans in general exist because someone telling you exactly what to eat is sometimes more effective than trying to give an understanding about why those choices are made.

The reality is that "healthy" is an individualized goal and different foods are a tool for getting to that destination.

FWIW: this might be a suggestion of the specific audit team you’re working with or a requirement of one of the “follow our playbook and you’ll pass” vendors if you’re using one of those, but the SOC 2 on its own doesn’t really impose specific technical feature/control requirements like this.

I don’t have the exact exam language in front of me right now but the requirement would be something like “you have some process for learning about, assessing, and mitigating vulnerabilities in software dependencies that you use”.

Enabling an automated scan and version bump tool like dependabot is a common and easy way to prove your organization has those capabilities. But you could implement whatever process you want here and prove that you do it on the schedule you say you do in order to satisfy the audit requirement.