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

They seem to follow the anti-corruption layer model for most of their offerings, so I would expect they use what ever OS is best supported by the upstream.

It is a large reason they can mitigate vendor risk IMHO, offering different tiers of switches as an example without being held hostage by on particular switch IC vendor like many brands.

I do wish someone would take up comstar though, netapp bought and killed several jbod lines etc… to kill it before Oracle bought Sun and also killed it to protect their enterprise storage offerings.

NVMe-oF may be a possibility because there are FPGA IP vendors but without comstar there are some challenges IMHO.


It is quite likely that the intermediate tokens don’t have ‘semantic import’[0]

There are methods like Habitual Reasoning Distillation or Inverted Reasoning Traces [1] that can help.

While there are reasons to hide the intermediate tokens from a IP protection stand point, there is also a need to hide more effective and efficient generating that doesn’t fit the R1 claims of an aha moment that has been debunked, but is a consumer expectation.

While hidden intermediate tokens do increase the difficulty, it is not a from barrier in itself, especially as they are billed, given information about their length.

[0] https://arxiv.org/abs/2504.09762v4

[1] https://arxiv.org/abs/2603.07267


For simple cases I just launch podman containers on long lived hosts with ansible.

You can still add pods if needed and the systemd integration works.

Plus you can actually improve isolation by co-hosting services under separate UIDs.

Like any container it is just co-hosting, and elasticity is a bit slower with autoscaling instances, but it removes most of the complexity of K8s which very few org benefit from or have the culture to support.


You can get 60tps with three 1080tis and the sparse model, and I bet two 16gb 5060tis would do the same for ~1200. One 3090 is enough for a useful system, even on an old am4 host.

Dual 5060ti 16gb does over 100 tok/s on 35B A3B. Even with PCIE Gen 4 x4, which quite a lot of motherboards can do. Though Gen 4 x8 or Gen 5 x4 is slightly faster. Misc working notes on this hardware combo here, https://github.com/jonnor/embeddedml/tree/master/handson/mic...

My workflow is too different right now (gradually constrained to network less builds for reasons) but I am really enjoying how zeds agents have worked out in the past few weeks.

I have 27b, 35B-A3B and a cpu backed gpt-oss configured and use them in parallel, checking if one is getting ratholed and adding context or manual fixes.

I had various other systems setup and commercial models but really don’t use them.

It may be too interactive for some people, but it is a good mix of fail fast and often the places qwen3.6 was failing was eventually problems with the frontier models.

And this is with the unsloth defaults and hardened llama.cpp podman containers.

I do sometimes load other models or honestly just feed things into google’s free agent. But that is rare and to be honest manually fixing is typically faster and less error prone


Any artifacts or blogs I can check out? I'm curious how you manage to make them all useful in parallel. I have a hard enough time getting one instance of Qwen3.6-27B being useful full time haha.

More that LoC is a simple metric that has always been a problem.

Non-Functional requirements is a vestigial term from ‘function point analysis’ which is from the late 70s, and which also ended up being a proxy for LoC.

The entire industry is so focused on measuring now, and incentives are so skewed to short term that lagging indicators like maintainability are a non starter in many organizations that it will be challenging to fix this time.


Which kind of sucks, when you emphasize and steer the agent(s) to more optimal solutions with less complexity and code.

Actually Linux was very SysV like back in the day, so it was more like the stuffy OS's that people liked.

GCC was the real catalyst, With even SUN which had used bundled dev tools as a early selling point was unbundling them and charging more, many x86 UNIXes like SCO didn't even come with a tcp/ip stack without an extra fee...and you couldn't take C code from HP to another system and actually have it compile.

As Solaris is really just a sysV-ification of the bsdish sunOs...the introduction of posix as a least common denominator, and Linux being closer to the commercial-ish unixes it was just an easier sell for a lot of users.

In hindsight it may seem silly, but in may projects I was involved with, linux using sysV /etc/init.d/, vs BSD's /etc/rc.conf was the driving factor, because /etc/rc.conf was a shared dependency and harder for us to modularize projects.

IMHO the real Linux advantage is that it was using the gnu user land, and thus gcc worked well with it and companies started to sell commercial support early.

But there were still flavor wars from all sides all the time, and being an ex-op on #unix and #unixhelp from the 1990s, I dealt with them all.

But BSD and heck even ITS etc... was the free-for-all, anything-goes, platform of record.


> IMHO the real Linux advantage is that it was using the gnu user land, and thus gcc worked well with it and companies started to sell commercial support early.

IMHO what really differentiated Linux were

a. the bazaar development approach, which lowered barriers to contribution, felt more transparent and "safer" with regards to what was going on in kernel land

b. the GPL, which while annoying to certain companies due to its viral nature, it at least guaranteed that no competitor could just develop a major innovation, grab the kernel and all of your contributions and run with them, undercutting you in the process

and also a noteworthy mention was the fact the BSDs were basically sabotaged by AT&T via their nefarious set of lawsuits, which nipped in the bud any semblance of advantage they had


> and also a noteworthy mention was the fact the BSDs were basically sabotaged by AT&T via their nefarious set of lawsuits, which nipped in the bud any semblance of advantage they had

People keep saying that but I saw zero evidence of those lawsuits factoring into any purchasing decisions that customers made.

I saw Solaris SPARK servers purchased for running Informix RDBMS

I saw Solaris deployed for payroll systems running Oracle middleware.

I saw FreeBSD servers built for web hosting

I saw FreeBSD servers built for ISP backend services

But at no point in the 90s did I see anyone running Linux commercially. In fact the only reason I ran Linux (Slackware) in the 90s was to see what all the fuss was about from my nerdy younger peers on IRC. And even then, I just threw it on a desktop PC.

In the 90s you had NextStep workstations used to build games intended for PCs (like Id Software did with Doom and Quake). And used at CERN for the development of the WWW.

UNIX was the 90s platform of choice for computer animation. It was the platform of choice for multi-tenant web hosting. And so on and so forth.

Much as Linux had the cool hacker community, 90s UNIX systems had superior ACLs, containerisation, faster TCP/IP stacks, significantly more stable file system drivers and so on and so forth. So people naturally chose UNIX for their important systems. And that’s exactly the trend I personally experienced in the 90s.

This isn’t to say that I think the unix wars had “zero effect” on the decline of unix, but I do personally think the amount of impact it had is massively overestimated. I think Linux would have taken over regardless because the Linux culture embraced everyone’s weird ideas vs UNIX systems that did extensive gatekeeping. And the kids that played with Linux because it was fun and hacking was encouraged, grew up and became influential in decision making.

I think the culture of Linux had more to do with Linux’s growth than anything else.

Personally, I don’t think the license made any difference here. I do get the arguments people make about GPL, but GPL was around since before Linux and it didn’t gain significant traction then. But like most of the opinions I’ve shared above, it’s an impossible point to prove either way.


You’re talking about architecture but I was talking about development culture.

Linux encouraged people to fork and experiment with it. Whereas the FreeBSD was a carefully maintained ecosystem.


I think you are a possibly a decade off on the timing here.

USL v. BSDi is what impacted the BSD side, and it was during that lawsuit before Novell bought USL etc.... that the problems were that allowed Linux to make gains while the net/2 distros were in a waiting game IMHO.

The timing absolutely helped Linux and GNU being packaged as a complete system by the various distros etc..., and common OSS distribution points like Walnut Creek and PHT were very much concerned about USL v. BSDi and in an era when you had to make long distance phone calls to download with a modem, a lack of CDroms etc... absolutely caused a dip in adoption of the BSDs.

By the time the IBM v. SCO lawsuits happened (2003) the UNIX wars were long gone and Linux was already established.

SCO/Interactive/Coherent/etc... and other x86ish UNIXes were quite common in my work in the early 1990s, but the whole unix wars is way to complicated to cover in a single post.

The post .com bubble SCO lawsuits really just didn't matter much, the consolidation that happened in the early 90's that ended the UNIX wars, plus Intel killing most of the commercial unix independent CPUs with Itanium untruths and impossible promises and an inability for the major vendors to adapt to a lower margin model etc... killed those off.

The SCO lawsuits were really just the flailing of a dyeing company which was the end result of WordPerfect buying Novell with Novells money and local Utah politics.


Sorry, I don’t think my point was very clear. I wasn’t saying that SCO sued Linux in the 90s nor that the UNIX wars had zero impact.

Just that FreeBSD was still used a lot in the 90s and managed (at least from what I experienced) to dodge most of the concerns that companies had deploying other UNIXes.

I mean, it’s not like UNIX use dropped to zero overnight.

So you did see a lot of Internet companies using FreeBSD as their platform of choice. For a while, it really did look like FreeBSD was becoming the dominant server platform in that domain. Not everyone too Linux serious at that time. It wasn’t until at least 99 when Linux became a viable competitor to FreeBSD.

But once Linux did gain favour its popularity sky rocketed. Which is exactly why SCO took various Linux shops to court.


Luckily someone with a time machine saw your post and added it to POSIX.1-2001 :)

(Sorry if you weren't joking) but yes, posix_spawn() has been a thing and in glibc fork is just a alias to clone()

Not exactly that OP idea, but fork/exec is legacy really.


other people in the thread say that posix_spawn is more or less implemented as a fork+exec wrapper though? it sounds like the idea is more like if there were a separate deferred_fork that made an intermediate "process factory" that let you set up a process without actually creating a new one until the exec. obviously the if() construct would have to be replaced with an in-process handle that mimics calls to the posix api.


It is hard to incentivize docs, and often when there are incentives they make writing docs painful (sharepoint) or time intensive (run books).

I am not convinced that just adding llm summaries to a commit will have long term value, especially if you don’t keep the ‘why’ separated from what is probably going to be a verbose how.

But I would be happy to be shown wrong here.


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

Search: