Hacker Newsnew | past | comments | ask | show | jobs | submit | nylonstrung's commentslogin

Unless I misunderstood it seems like this is trailing the pareto frontier in cost and speed.

Compare to providers like Fireworks and even with the openrouter 5% charge it's not competitive


our SLA is actually higher and we are lower priced. We are also using this as a step into serving finetuned models for much cheaper than Fireworks/Together and not having the horrible cold starts of Modal. We're essentially trying to prove that our engine can hang with the best providers while multiplexing models.


According to the providers that I keep track of, Cumulus is typically pretty price competitive, except for MiniMax where DeepInfra and Together are much cheaper and GLM-5 where DeepInfra and z.AI's own hosting is much cheaper.

(Also technically qwen3 8b w/ novita being first place but barely)


It's unfair to act like NixOS just breaks "randomly" or is inherently unreliable

It's essentially deterministic and fully reproducible.

Issues with Bluetooth, electron etc as described are essentially irrelevant to NixOS and have to do with your configuration


It's possible I have no idea what I'm talking about, but my understanding is that nixos relies on fetching things from third party URLs which may simply die. I feel a bit misled by the promises of nixos, because I cannot actually take the configuration files in 10 years and setup the system again due to link rot.

I was also under the impression that I could install DE's side by side on nixos and not have things like one DE conflicting with files from another DE, but this apparently isn't true either - I installed KDE, and then installed Sway and Sway overwrote the notification theming for KDE.

NixOS is very impressive but the marketing around it feels misleading. The reproducible claim needs a giant asterisk due to link rot.


Every system and package manager will be affected if it cannot download source code to build a package.

NixOS less so, because pretty much all source downloads that are not restricted by license are a separate output that will therefore be stored on (and downloadable from) NixOS cache servers.

I'm not sure what your expectation for this is in general, nobody can just wish into existence data that is just gone.


> I installed KDE, and then installed Sway and Sway overwrote the notification theming for KDE.

That sounds like you are using the nixpkgs modules to install the desktop environments (programs.sway.enable) rather than only installing the packages (environment.systemPackages = [pkgs.sway];). Both are valid, but there is a key difference:

The packages themselves cannot cause such conflicts because each package is just a separate folder under /nix/store. Nixpkgs modules both install the package _and_ configure additional settings which means that modules can interact with each other and possibly cause conflicts.

You can see it in the source for nixpkgs. This config block is applied whenever programs.sway.enable is true: https://github.com/NixOS/nixpkgs/blob/0590cd39f728e129122770...

It installs the sway package here: https://github.com/NixOS/nixpkgs/blob/0590cd39f728e129122770...

But it also edits other settings like adding sway to the display manager session packages list: https://github.com/NixOS/nixpkgs/blob/0590cd39f728e129122770...

What surprises/confuses me is: sway doesn't have notifications. You have to install your own (personally I use mako). So I'm wondering if this was a much greater change like system-wide gtk/qt theming, or did you also set up a notification daemon for sway and perhaps it was the module for _that_ which altered your KDE notifications.

(Just to be clear: I believe you that your notifications looked different, I'm just wondering about the mechanism through which they were altered.)

Personally, I don't like surprises so for 90+% of my config, I only install the packages (environment.systemPackages) rather than using the modules (programs.sway.enable) but that does mean I am essentially re-inventing the module for each package inside my own config which is a lot more work and requires a lot more nix proficiency.


> NixOS is very impressive but the marketing around it feels misleading. The reproducible claim needs a giant asterisk due to link rot.

It's a valid concern, though perhaps worth mentioning you will be able to restore your 10-year old config as long as the files downloaded from now-broken links are still in the Nix cache. Of course in practice, this is only useful to large organizations that have resources to invest in bespoke infrastructure to ensure supply chain integrity, since any `nix store gc` run will immediately wipe all downloads :(


Imagine a program with a compile error, nicely wrapped into reproducible build system (like a docker with tools or nix).

It is deterministic - compilation fails at the same line every time.

It is fully reproducible - anyone can get the same compilation error.

And yet it is not reliable at all, it's completely broken.


> the benefits are basically minimal/none

Sounds like you've never used it. I've daily driven it for ~2 years and would never go back

It works great with containers, you can use Nix to build extremely lean OCI images. Mercury uses it this way- the book NixOS in production discusses it


Just seems like it’s a solution for a problem I don’t have.

I have to learn a whole new language that’s only used for NixOS just to do things I already have no difficulty doing with existing tooling.

I enthusiastically say, no, I’ve never used it, because, like I said, having that kind of learning curve just to set up an OS is kind of insane. Doesn’t matter if it’s the greatest thing since sliced bread.


Appreciate this, very cool of you to do that


It sounds like a "cursed problem". Are there any contemporary techniques that show any promise?


Great article. I foresee people rediscovering 'Test Driven Development', probably with a new buzzword slapped on it


Reinforcement learning with program feedback


Agentic Reassurance Patterns


I'm not sold on diffusion models.

Other labs like Google have them but they have simply trailed the Pareto frontier for the vast majority of use cases

Here's more detail on how price/performance stacks up

https://artificialanalysis.ai/models/mercury-2


I’d push back a bit on the Pareto point.

On speed/quality, diffusion has actually moved the frontier. At comparable quality levels, Mercury is >5× faster than similar AR models (including the ones referenced on the AA page). So for a fixed quality target, you can get meaningfully higher throughput.

That said, I agree diffusion models today don’t yet match the very largest AR systems (Opus, Gemini Pro, etc.) on absolute intelligence. That’s not surprising: we’re starting from smaller models and gradually scaling up. The roadmap is to scale intelligence while preserving the large inference-time advantage.


This understates the possible headroom as technical challenges are addressed - text diffusion is significantly less developed than autoregression with transformers, and Inception are breaking new ground.


Very good point- if as much energy/money that's gone into ChatGPT style transformer LLMs were put into diffusion there's a good chance it would outperform in every dimension


I changed my mind: this would be perfect for a fast edit model ala Morph Fast Apply https://www.morphllm.com/products/fastapply

It looks like they are offering this in the form of "Mercury Edit"and I'm keen to try it


It's extremely similar to the fake "agentic" crypto plays a year ago

Where Goatseus Maximus and stuff supposedly created coins and invested autonomously.

Obviously it was BS but it fueled a huge amount of attention and speculation


I hate these Lovable-generated slopsites


BAR is incredible, probably best RTS right now


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: