Surprised this is not bigger on HN, seems like a pretty big deal that Ilya Sutskever is claiming what sounds like a breakthrough. I expect that within the next 12 months they should release something significant with that compute.
It'll be interesting to eventually find out what they've been working on, but this update in of itself doesn't give much to discuss, other than perhaps NVIDIA being their partner.
From the little Ilya has previously said, it sounds as if SSI is working on learning algorithms, perhaps some combination of better generalization / sample-efficiency and continual learning.
It's hard to know how seriously to take the "super-safe" part of SSI's name, although this announcement does talk about them developing "robustly aligned" AI. Ilya has previously talked about the role of emotions in human learning as as part of the human "value function", so perhaps some sort of artificial emotions will be used to assist learning and try to provide "robust alignment" (easier said then done without millions of years of co-evolution).
The NVIDIA announcement also says "The two companies will also collaborate on the technical advancement of NVIDIA’s current and future compute platforms, leveraging SSI’s unique insights into the future of AI". This seems like a bit of clue - that SSI are doing something that may steer the hardware in a bit of a different direction than current pre-trained transformers are doing.
Putting it all together, if I had to speculate, I'm guessing that at least part of what SSI are working on is indeed continual learning, and that they see this as resulting in per-user individualized models that might make most sense to be run locally, a future that that it seems NVIDIA may support.
> ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB.
V8's Orinoco is also pretty good now. It's improved a lot over the past decade and is now mostly-parallel. (A decade is about how long one of these things takes: high-performance GC is hard.)
I'm also a fan of MPS: it's a big of dark horse because it's more a GC construction kit than a ready-to-go GC, but it's fast and flexible, and I'd start with it any day over Boehm if I were making a VM from scratch.
If I were writing this language, I'd probably just compile it to Go, although that means Rust extensions would either incur cgo costs or have to be replaced with Go extensions.
It's barely more expensive than a direct function call but, not so you'd notice unless it's in a hot loop. At which point the lack of cross-language inlining is your real problem.
Do you know of any articles, tests, or implementation breakdowns that show this. I don’t have the personal experience to agree, but if that’s the case Inwould really like to know how the improvements were achieved.
Various GCs can go faster now too. JEP 376 talks about hundreds-of-microsecond work done in pause now that GC no longer has to scan the whole stack.
That said: 1ms? 1ms is getting into the sorts of latency the OS and hardware impose on your program no matter what it does. For example, on x86, a SMI can take 300us, or 1000us if you're unlucky. I've seen softirqs for shitty wifi chips take a hundred milliseconds! And God help you if you take a hard page fault:
You're worried about 1ms latencies, right? So you're mlock()ing all memory? Running RT threads pinned to cores? Carefully using PI and static priorities to avoid inversions? Avoiding blocking IO everywhere, not even for graphics page-flipping? Managing thermal headroom to avoid involuntary clock collapses? And it should go without saying, but I have to ask: you're running a PREEMPT_RT kernel, right?
No? You're not doing any of these things? Then why are you worried about 1ms in GC?
I think this is a situation where the term systems programming is too un- or ill-defined to be anything but a semantic argument in waiting. I am not particularly fond of the broader meaning systems programming has taken on but I understand it. As a term of art for developers systems programming now encompasses:
- infrastructure development like Docker and Kubernetes
- general utilities programming like grep, terminal emulators, compilers, etc
- performance sensitive artifacts like OS kernels, video/audio codecs, hardware interaction layers
and more in common usage. Without some sort of communal understanding of the taxonomy of development areas discussing things like GC in systems programming becomes tedious and often prone to arguing past people due to conflicting understanding of terminology.
I do think there are genuinely ripe areas of research and development for performance and determinism sensitive memory management and subsequent outreach to make sure the potentially effected developers and language designers actually have a chance to evaluate any advancements. But it sure seems like it would take an act of ‘developer congress’ to make sure people were talking about the same things.
What are you describing as a frame update? I am trying to be as generous as possible to your comment and thereby assuming there is a disconnect between my understanding of ‘frame update’ and yours. Genuinely curious, because that term as I am familiar with it means the entire time allotted to generating and rendering a single frame for display. If that’s what you meant, you are asserting that a ‘modern game’ is typically running at 333 fps. I am typically using the term ‘modern game’ to describe newly releasing AAA games nearly all of which struggle on many hardware configurations to achieve a steady 60 fps (which is 16 ms per frame).
e-sport competitive games target either 128Hz or 320Hz update frequency. Two rules of thumb: first if you want to actually get 60Hz every frame (e.g. on a console where 1st party validation cares about this more), then you attempt 120Hz so jitter only brings you down to 60Hz. Second, a bit more than half of your time is spent doing other things. So the amount of time you actually have to spend on world-update and/or render logic is only about half of your allocated time to start with. That's two independent factors of two there. I would have targeted 90Hz to start with, which gets you to about 3ms of actual time per frame.
Game GCs are interesting because you know that the execution is structured like this and you know how much time you have left before you have to switch back to application code for the next frame/time step. There's interesting optimizations you can make around this and could almost completely avoid user-observable GC pauses.
same — that was an unexpected little moment on HN. Honestly appreciated the answer as it caused me to stop and examine the phrase I've been using/hearing without never really thinking about it.
What's everyone's experience with modern PF in production? Also, not to start a holy war, but what people think about modern PF vs nftables? I've only ever used nftables (and only in fairly simple scenarios) but I've always been curious about the PF side of the world.
I manage a pf.conf with about 400 rules across a dozen VLANs, I find it intuitive and even enjoyable to work on. It feels kinda like editing source code - there are some host, network, and port declarations at the top, a section for NAT and egress, then a section for each VLAN that contains the pass in/pass out rules.
I tail the pflog0 interface in a tmux session so I can keep an eye on pass/block, and also keep a handy function in my .profile to make it easy to edit the ruleset and reload:
In my experience, PF operates a LOT more like commercial firewalls in how you think about filtering and NAT.
In Linux, even with nftables you still have the concepts of "chains" which goes all the way back to the ipchains days. IME this isn't a particularly helpful way of viewing things. With PF you can simply make your policy decisions on in or out and on which interface(s). Also I'm not sure I ever saw a useful application of why you'd apply a policy on the pre/post-routing chains that wasn't achievable elsewhere in PF and in a simpler way.
Also I've never been a fan of having a command that just inserted or deleted a policy instead of working from a configuration file. (nft "config" files are really just scripts that run the command successively.) I get why some folks would want that (it probably makes programmatic work a lot easier) but for me it was never a benefit.
Anyhow it's been a long time since I've had to do this kind of thing so maybe I'm out of touch on the details. Happy to hear about how I'm wrong lol.
I haven't used Linux as a gateway in years, so I can only compare pf to iptables. The two biggest differences are the way the rules are applied and the logging.
pf rules work a little backwards compared to iptables. A packet traverses the entire ruleset and the last rule to match wins. You can short-circuit this with a "quick" directive. It takes a bit of getting used to coming from iptables.
The logging on pf doesn't integrate with syslog automatically like iptables does. You're expected to set up a logging system for your particular use case. There are several ways to do it, and for production you'd be doing it regardless, but for honelab setups it's an extra thing you need to worry about.
I prefer pf, but I don't recommend it to people new to firewalls.
It's fine if all you need is a packet filter, but in 2026 I question that many production use cases can get away with just packet filter.
As a host firewall, it's obviously fine, I assume your question is about using pf as a network firewall. Given the threat landscape, you usually want threat protection. At the very least that means close-to-real-time updates from reputation lists. You can script that with pf, but it's not fun. Really, you want protocol dissection and - quite possibly - the ability to decrypt on the box and do payload analysis. Just doing packet filtering doesn't buy you all that much anymore these days, and anything production that requires compliance or that you genuinely care about should be behind what you might also call IPS or layer 7 firewall capabilities.
pf doesn't do any of that. You don't have to use Palo Alto or Cisco for this, either.
If all you need is packet filtering, it's a good option, though.
I'm just glad we don't have to deal with iptables anymore. That said, due to iptables -A crap being embedded in countless tutorials and LLM FFN-head weights, we'll end up needing to keep it fresh in mind for decades to come.
Their BDFL thinks BC breaks are great “we’ll be in a better place” I remember him saying, and has blessed breaking pf multiple times by changing the rule syntax, whereas prior versions of this book are suddenly obsolete along with countless tutorials, forum posts, etc.
This is one thing M$ gets right, in business environments you don’t do that. I wouldn’t use pf for anything outside a home lab.
Can you add an email to your profile, so I can reach out to learn more? I'm really into air quality and been trying to improve conditions in my apartment. You mentioned that
> Generally learn about diffusion in wall construction materials and figure out where organic material is used in your house. If organic material is next to something that limits diffusion (plastic, foam, metal, concrete, cement, paint) it is a possible point of water condensation and mold growth.
which is super interesting — I've found a couple of electrical sockets in my apartment which have a very strange smell, similar to soil/mold (I've confirmed that with other people, just to reduce the chance that I'm crazy). I'm still trying to investigate/fix the issue, and it seems that you know more about that, would love to learn from you.
Thanks for sharing your thoughts, very interesting!
Thanks for your kind words. I've added mail to profile, feel free to reach out.
If you are into air quality monitoring you might like homeassistant either with DIY sensors based on esphome (quite easy if you like very basic tinkering with low voltage) or with some off-the-shelf IOT products. If you just want to have a reliable CO2 sensor I can recommend the aranet4, but unfortunately those are quite expensive.
I had some electrical sockets which were super corroded from the humdity, so that the copper wire turned black even though the plastic wrap of the cable was still on it. The humidity must have moved up the cable for ~10cm. The mold damage that I found a year later was at the same wall, but I didn't mentally connect these two things at the time.
Re AIQ, I've actually built a couple of devices myself (using different sensors, plantower being the most popular one, but I've played with sensiron and others as well) but I've mostly focused on the PM monitoring.
The sockets that have strange "smell" are actually on the (inside) wall that is the building boundary (i.e. not a wall with a neighbour — these sockets don't "smell"). Still, it's a bit shocking to me that this could happen. Do you know how the humidity "got" onto your wall? How were you able to find out? I'm pretty early in my mini "investigation".
Yes, it might've been lost in translation but my socket also was located on the inside of an exterior wall of the building. So one side was room other side was outside. If all your problematic outlets are located like this, then it might be a condensation/insulation problem.
Obviously you should rule out a leaking pipe, especially if someone created a slow leak by putting a nail into a wastewater pipe, and also rule out a damage to the outside of the wall where rain could come in.
Maybe you can find out if there was a change to the exterior walls after the house was originally built, for example someone insulating the building by putting foam mats on the exterior walls during the most recent "renovation", or putting insulation wallpaper on the inside of the exterior walls. When houses are originally built, normally experts ensure with calculations that no condensation problems will happen within exterior walls.
But after many decades people think they are clever by putting additional insulation on the exterior walls in order to save some money, or to simply change the style of the building. In worst case, additional insulation will move the dew point towards the inside of the wall, and then condensation of warm+humid indoor air will happen within your exterior wall. If it is a wooden building like it's common in the US this can create a mold problem. But it can also be a problem for stone buildings like we have here in Germany, if a wallpaper of wallpaint is used that prevents humidity that is trapped within the stone wall from evaporating.
Once you know what materials were used for your exterior wall, you can use a very nice calculator [1] that will show you if the wall has a condensation problem or not. For this you need thickness and material for every single layer of the outside wall.
Curious about the deal value/price — any clues whether it was just to make existing investors even (so say up to $30M) or are we talking some multiple? But if it's a multiple, even 2x sounds a bit crazy.
One option is that the current Bun shareholders didn't see a profitable future and didn't even care if they were made even and a return of the remaining cash was adequate.
Another option is that this was an equity deal where Bun shareholders believe there is still a large multiple worth up potential upside in the current Anthropic valuation.
i don’t get it either - bun being the foundation of tons of AI tools is like a best possible outcome, what were they hoping for when they raised the money? Or is this just an admission of “hey, that was silly, we need to land this however we can”? Or do they share major investors and the therefore this is just a consolidation? (Edit: indeed, KP did indeed invest $100M in Anthropic this year. I’m also confused - article states Bun raised 26M but the KP seed round was 7, did they do the A too but unannounced? Notably, the seed was summer 2022 and chatgpt was Nov 30, so the world is different, did the hypothesis change?)
Would it make sense to have a similar feature in Codex CLI? I often do "spec-driven development", which is basically a loop of:
research -> implementation plan -> actual implementation (based on research + plan) -> validation
I have multiple subagents that I use for each phase that (based on subjective judgement) improve the output quality (vs keeping everything, every tool use etc. in the "main" context window).
Codex CLI is great and I use it often but I'd like to have more of these convenient features for managing context from CC. I'm super happy that compaction is now available, hopefully we'll get more features for managing context.
I didn't know about these ads, thanks for sharing! Can't imagine how people reacted to that when they aired — the things they described sound so "normal" today, I wonder if it was seen as far fetched, crazy or actually expected.
I was in my late teens at the time. My memory is that I felt like the tech was definitely going happen in some form, but I rolled my eyes heavily at the idea that AT&T was going to be the company to do make it happen.
If you’re unfamiliar, the phone connectivity situation in the 80s and 90s was messy and piecemeal. AT&T had been broken up in 1982 (see https://www.historyfactory.com/insights/this-month-in-busine...), and most people had a local phone provider and AT&T was the default long-distance provider. MCI and Sprint were becoming real competition for AT&T at the time of these commercials.
Anyway, in 1993 AT&T was still the crusty old monopoly on most people’s minds, and the idea that they were going to be the company to bring any of these ideas to the market was laughable. So the commercials were basically an image play. The only thing most people bought from AT&T was long distance service, and the main threat was customers leaving for MCI and Sprint. The ads memorable for sure, but I don’t think they blew anyone’s mind or made anyone stay with AT&T.
We’re the same age, and I had exactly the same reaction.
AT&T and the baby bells were widely loathed (man I hated Ameritech…), so the idea they would extend their tentacles in this way was the main thing I reacted to. The technology seemed straightforwardly likely with Dennard scaling in full swing.
I thought it would be banks that owned the customer relationship, not telcos or Apple (or non-existent Google), but the tech was just… assume miniaturization’s plateau isn’t coming for a few decades.
In these commercials, it wasn't the technology itself but the ease of access and visualized integration of these technologies into the commoners' everyday lives that was the new idea.
