It might not be as smart, though my employer gives me access to Claude, so I tried giving the same task to Opus 5.5. Both DS4.1 Flash and Opus5.5 produced nearly identical outputs.

After that, my company switched the entire engineering department to Azure hosted DeepSeek4.1 and costs were cut by 3/4. So far, no one has really noticed the change.

Comments URL: https://news.ycombinator.com/item?id=50054600

Points: 1

# Comments: 0

This perspective I can't wrap my head around. Like I get that you wouldn't use it, and that's fine - but if Linux was available and we made it incredible, that would push Apple (and Google) to do better. So you'd get a better MacOS / iOS by proxy.

Like, don't we want competition? What motivates people to desire an unchallenged status quo?

It's better than Windows 11 at least - though we probably can't credit that to improvements to the Linux DE

It still has tiny market reach. Very few people are going to invest the time needed to build a quality user experience for like 1000 users.

Just imagine what would happen if Linux could be installed on the iPhone. There would be SteamOS distributions within an hour of the announcement.

> It’s funny that you mention Waydroid. It throws most of Android’s strong security model out of the window.

Haha yea, it's more an example of capabilities that could be rolled into highly polished user experiences. Again, if Linux could be installed on the iPhone - I'm certain Waydroid maintainers would shut the project down from PRs.

~~* competition *~~

If I would draft policy that could make it I'd suggest;

- Scoped to companies above a "number of units sold globally" threshold.

- Documentation must be supplied 3, maybe 5 years after hardware release (similar to "generic drugs").

This means small hardware startups are not burdened by the overhead in creating docs, and megacorps retain the ability to extract profit during the period of maximum profitability for the product. The eventual expiry would encourage companies to innovate (I think malicious compliance is unlikely).

With the recent push to decouple dependance on US technology companies, I see this as possible (though still unlikely) in the EU, perhaps Canada.

I'd be fine with that model - let them make money for 5 years recouping their R&D costs, then they must offer documentation so the community can repair / maintain the hardware themselves.

I personally see it as falling under "the right to repair" and selfishly, I know we can do more with the hardware than they are demonstrating. It's endlessly frustrating that we are not allowed to and then the devices just disappear forever.

Look at Asahi. Almost a decade in and we can use the GPU at like 30% of its ability on 6 year old hardware.

That a project with major interest. No one cares about spending a decade reverse engineering the hardware on a Google Pixel or Samsung Galaxy.

If they gave us proper full hardware documentation, we could create high quality alternatives. Again, we can't so you don't see it.

Competition is good. We should always advocate for things that enable competition.

Once we can actually target the hardware, open source alternatives will be much better than first party options.

You can already see the potential in the open source world.

Linux has Waydroid so Android apps can be run on Linux at full speed without emulation. That means, if you had a Linux phone, you have the entire Android library - the only thing lacking is the launcher. How hard is a launcher to program? It's just Steam's big picture mode.

Other examples of the nice things we can't have; FEX lets you run Steam games on phone hardware. Open source drivers can unlock displayport over USBC. Instantly your phone becomes a thin client / laptop replacement that can play PC games (poorly, but 1080p games are possible).

We are _not allowed_ to do these things. I love OS development and, if I was allowed, I'd make iOS look like janky trash.

There's nothing inherently special about their optimisations, but hardware is incredibly complex and without documentation, open source drivers cannot be written that are anywhere close to what engineers with hardware docs can build.

Asahi Linux is a great example. It's an unbelievable project but still far from first party Apple drivers.

Once the hardware can actually be used, competition in the OS space will follow.

They have no incentive to offer documentation and competition is bad - so they won't allow that. Regulators must step in here.

Drivers and firmware are the biggest hurdle outside of locked bootloaders for competition in the operating system space.

Examples; Anything Apple (MacBook, iPhone), anything Samsung, anything Google, the list goes on.

There _is_ open hardware, but it has poor performance / battery / build quality and the vast majority of users will not accept that.

IMO "the right to repair software" is essential and this duopoly is a function of explicit monopolistic practices.

Maybe LLMs can help open the "reverse engineering" Pandora's box - but we have yet to see that realised - at least for drivers / firmware

Comments URL: https://news.ycombinator.com/item?id=50016155

Points: 5

# Comments: 1

Why? If you embed Node.js then the developer can develop against Node.js if they want to. It's the same as writing Cloudflare or AWS Lambda functions.

> Not to mention that it's much easier to reason about contracts and behavious within a single language.

That's arguable and depends on the way plugins are supported. MCP is a good example. It's IPC with a well documented JSON API. You can write your MCP server in any language you want and practically every language has bindings for it (it's also trivial to point an agent at the spec and have bindings generated).

> You get the worst of both worlds and that's probably why the most harnesses tools don't do that.

Almost all harnesses support ACP (pretty much a cross language plugin system) and that has enabled harness integration into VSCode, Zed and a plethora of "software factory" tooling. The same goes for MCP (also a cross platform plugin system). We do it all the time.

First mover was a huge part of developing low-effort MVPs but we are passed that point now. You're not going to be the first to market now, so you have to be the best in market.

> What you're describin already exist but the target audience for such is small

I'm not sure what you're arguing for? Are you saying that you think it's acceptable that that multi-billion dollar companies with strong engineers and unlimited token budgets ship low effort products that waste the limited resources available on consumer devices?

Like, if Pi/Claude/Codex/etc used a fraction of the resources and your experience as a developer or plugin developer was unchanged - you're opposed to that?

Are you okay with Microsoft shipping a broken operating system because it's good enough compared to the competitors?

Haha sorry, it's hard for me to comprehend not challenging those with the money and capability to ship great products... not shipping great products.

> I invite you to try and watch the adoption :) It's just a prompt away.

I am actually writing a native harness that is a pixel perfect clone of the Codex Desktop harness haha. I expect no one to use it because adoption is not about quality, it's about marketing and that is dominated by a handful of players.

That's not going to stop me because I'm doing it for fun, but if I can do it with a handful of DeepSeek tokens and a few weekends - there's no excuse for the big players not to.

You could write them in Go, TypeScript, Python, whatever. If you wanted to write your plugin in Rust, you'd need the Rust toolchain though, yes.

Plugins don't need to be in the host language. It's up to the harness writer to ensure the plugin engine makes sense for the patterns of plugin writers.

Then it's up to plugin writers to ensure their plugins are performant so people enjoy using them.

> And plugins for executables suck compared to "just create a .ts file in this directory and edit/test it in a few seconds until satisfied".

Not really? Deno, Node.js are both embeddable within a native application, so plugins can be written in TypeScript without any change in expectations from the plugin dev's perspective. There's also QuickJS and LLRT which use like 1000x less resources than v8 (faster for plugins, slower for servers).

No one is asking plugin devs to change, just that the harness writers provide better platforms to build on top of

When was the last time you patched Pi / OpenCode / Claude dist or source code before running it?

Most people use plugins, and native apps have no issues with that.

This is more about demanding more of the big software vendors than it is about making an argument for the general software developer to write programs in Rust or Go.

We are talking about trillion dollar companies with highly paid engineers and unlimited token budgets.

As someone who has been writing TypeScript since the beta and started writing Rust professionally only 5 years ago, I'm about as productive in Rust as I am in TypeScript - so if I were distributing software, I'd want to ensure the end user has the best possible experience and that's hard to achieve with the node/python ecosystem.

"Run this bash script to install my CLI tool" behind the scenes it downloads a full copy of Node.js, installs the npm dependencies, add executable scripts for the entry points, updates PATH. It takes almost a second to start up, has no threads and uses way more memory than is necessary. Extend that to Electron applications which not only bundle Chromium, but also bundle Node.js - that's two v8 engines running and a process that starts with a memory footprint of almost a gigabyte.

Compare that to just downloading a portable self-contained single executable and running it. No package manager, no install scripts - just double click.

The end user is not installing cargo, compiling, or anything - they just run the binary.

I love alternatives to the big players but why is everything written in TypeScript or Python and takes up a gigabyte of ram.

I don't want to `npm install -g` something, just give me a single statically compiled binary that does the thing.

AI lowers the barrier of entry to Rust to virtually 0. As a side experiment, I have been rewriting Codex Desktop in Rust using native desktop APIs (gpui) and have made a cross platform copy that works on Windows, Linux, and MacOS. It runs at 120+fps and uses 40mb of ram. It's not that hard.

In a previous life, before the layoff times, I was working on a FaaS platform. If you need plugins, embed v8, quickjs or wasmtime/wasmer/etc.

People are acting like AI didn't eat up all the RAM on Earth. I had to sell my left kidney for the 8gb ram upgrade in my MacBook