My first job was at Westinghouse instrumenting a nuclear power plant. Our entire hardware-software package was a freebie given to the customer as part of a $200 million refueling contract (and that's in 1988 dollars). We, a team of 10, created a bespoke application stack which was effectively a web browser. The client machines were Sun 3 workstations. The server was some industrial mini computer that didn't have a TCP/IP stack - so we did in fact have to roll our own network stack.
Hah, the first engineering job I had was on Ovation DCS doing power plant controls. That system traces the lineage to the WDPF systems.
Was the server you mention here the actual DCS? With the Motorola CPU's? Running vxworks? Pretty cool recognizing something niche that is still, vaguely familiar. :)
The plant computer wasn't a DCS. I think it was a DEC. It gathered data from the control systems and instrumentation and had a bespoke in memory realtime-ish database. That database was then partially replicated down to the Sun workstations (code the 23 year old me wrote). Then the browser consumed that via a unix shared memory interface.
This article might be a bit tongue-in-cheek but it's actually something I've been thinking seriously about for a while. I can imagine a future where every country and company writes their own operating system and that might actually be a very good thing. There is a security advantage in not using popular technology stacks and rebuilding everything public-facing in-house. Because with Mythos-level AI capabilities, it is almost guaranteed that anyone with access to Mythos/Cyber can find a zero day in your stack. If your stack is proprietary and bespoke with no public access to source code it's much harder to find vulnerabilities, because they can only probe your public facing interfaces.
They won't be compatible with each other, guaranteed. Compatibility in reality comes from everyone using the same reference implementations that have been compatibility-tested, not from everyone implementing the same specifications.
I used to do this work in the IETF. take draft specs and write a C implementation and compare notes with the spec authors and other implementations. sometimes I would find a bug later on and see the same bug in multiple vendors implementations, and I would send them mail describing the issue and the fix.
its been very sad for me to see standardization get ignored, and the implementation become the point of reference. for a long time the only way to implement QUIC was to try to extract it from the Chromium code base - a pointless waste of time. but they spec for years was a couple of pages of meeting notes and a sample compression dictionary.
if we continue down this road we are impeding our own ability to evolve. if compatibility is defined by the implementation then were left with nasty balls of antiquated source that we carefully move around and try to plumb into our new environments, but no one really understands.
at the core, things like IP are very straightforward. we can and should specify the semantics of every bit, and have a wide variety of other implementations to test against. this provides a path for us to build new techniques and environments that are still useful in the world that exists today.
I would seriously recommend against building your own network stack for production use. Or writing your own web server for production use. Or database (whatever SQL or NoSQL) also for production use.
These sort of things are more complicated than you could expect and have plentiful pitfalls. Whatever you can do in reasonable amount of time is probably not that good compared to existing alternatives.
If you have actually pressing reason to build one and are ready and have means to spend time and effort on it go ahead. But carefully consider the effort needed...
holy shit. I was just tinkering with my production Laravel stack serving thousands in production trying to figure out how to improve worker concurrency (running out of RAM) and I encounter a random comment on HN which appears to solve my exact problem. This is so serendipitous
The real nightmare scenario is not just finding a vulnerability in the Linux network stack but finding vulnerabilities at the protocol level in TCP/IP itself or HTTP. That’s a problem that cannot be fixed. Has there ever been a precedent for this in computing?
A while back I wrote an FPGA-based minimal network stack to work with the MRMAC hard IP of an AMD VC1902 with basically the same functionality: ARP, IPv4, ICMP Echo reply and UDP send/receive. I added the bare bare minimum to get UDP GRO working on the receiver side (Linux).
I also enjoyed the learning experience and works perfectly fine at up to 100G. But I definitely appreciate that I didn't have to go through the same pain under Linux where this stuff just works.
This is just an opinion and not a very sensible one at that. The Linux TCP/IP stack is one of the most scrutinized network stacks in the world and more than likely free of bugs that coud lead to a server takeover.
Good to see that people still have this spirit of rolling their sleeves up and doing something like this for fun. Underneath it there is a very real point about mono-cultures and the increased magnitude of the impact of a risk, although more eyes checking one implementation should reduce the probability.
Everyone should build their own ** is the general advise I would give just about anything. Otherwise it is hard to appreciate how much effort it goes into things that we take for granted.
Everything looks simple from the outset until you try to build it yourself.
I recently saw this guy on HN who had written a web server for an Atmel AVR and also implemented a TCP/IP stack to boot. It obviously was far from feature complete, but it did work. He used SLIP to communicate with the "server."
We do these things not because they are easy, but because we thought they would be easy.
I also think there is an incredible transference of skills from one domain to another. This is a risk (everything looks like nail when you have hammer), but there are many domains that are very mature where you can learn a trick and apply it to a new domain over and over again.
My point is that it is a great way to learn and be more appreciative of what is done and why - network stacks, graphic stacks, web, etc - before being too critical of them.
Besides, statements such as "$7B for a proxy" or "it is just a wrapper" or "we can build it in-house" mostly come from those that have not had any measure of the scope due to not having any real experience with the said problem.
Back in the 8-bit days, we all wrote our own kernel process schedulers in order to make simple games. If you had an Apple II and wanted music, you'd need to make yours a hard real time one as well.
Prediction: as agentic code generation gets better, more and more code will be written JIT for it to be executed for security reasons. The engineer of the future is not only the one who uses agents to code, he uses agents to code each time "the" program is ran.
What's there to gain security-wise? Nondeterministic generation & then execution of that code without proper verification seems to be the opposite of a good security posture.
Proper verification would be deterministic rules the JIT-ed code would be checked against, so it would have to be non-JIT. Since the comment is talking about using more & more JIT for security reasons, I assumed it extended to verification too.
I don't get why you'd generally switch to JIT for security reasons.
Because after proper verification you very much aren't at JIT territory. Take the network stack. From my memories a proper commercial test suit from say Defensics is from a few thousand to tens of thousand cases. For each of Ethernet, IP, TCP and UDP. Any decent coverage however fast will take some time. Most likely lot more than you want with just in time...
Yeah, the cost of running the test suite every time an agent generates code JIT would be the killer for running it at scale. I didn't even get into practicality of that approach too much because the gist of it for me was the question of agents writing code JIT having security benefits (?) - the verification thing is a sidetrack.
Certainly, adding agentic JIT code invites more complexity to properly do it, so what are the benefits that call for introducing it.
Ok so if it is indeed possible to verify the code after JIT generating it, I still don’t understand why you would assume that in the hypothetical scenario we aren’t doing that verification?
You literally said it can’t be JIT, I’m just saying it seems like it can.
> Since the comment is talking about using more & more JIT for security reasons, I assumed it extended to verification too.
I wouldn't consider feeding the JIT-ed code to a JIT-ed verifier code proper verification.
Even ignoring the verification bit, I don't see the security benefits of having agents write JIT code, hence the original question. Because there might be some edge cases I don't know about, but I can't see this applying generally.
If you're doing formal verification, why are you JIT generating Code? Is the formal verification also being JITd? How do you know the agent wrote a good spec?
I don’t know why, but it’s certainly possible to imagine JIT-generating code and then verifying it. Which is why I asked why we were assuming the verification wasn’t happening.
I doubt it. It seems far more likely that such code will be written just once by LLMs, but in a way that allows its claimed guarantees to be formally verified (e.g. in Lean). At that point there’s no need to JIT an implementation each time.
My bet is one ultra-hardened, minimal, front-facing system which does N-modular redundancy which N systems, each written on a different stack/different language.
The hardened software picks the computation that wins the majority.
It's not an issue to write all the implementations in the various stacks/languages: we'll have better and better LLMs to help us.
This shall bring security and shall allow to detect shitload of bugs (both in the implementation itself but also in the stack).
Heck, this could even be compatible with GP: one of the implementation could be JIT'e by a LLM, others could be written in advance (and Lean formally verified). Not sure which sense it'd make though.
I'm 99.9% sure it's coming for if it's not, I'll make one.
So do I. According to today’s prevalent tech/science culture, “everyone” should
- write their own network stack, compiler, text editor, operating system
- learn 3-5 foreign languages
- travel extensively
- learn how computers work from the silicon principles to the userspace
- have a complete understanding of algorithms and data structures before even attempting to build anything, because nothing else will do
- read obscure Russian poetry
- “deeply” engage in 5-10 different philosophical practices and meditation techniques
- work out regularly, but according to strictly scientific principles, which you first have to research by reading a dozen books
- appreciate fine art, homestead food, and family life
Sorry folks, y’all are just Instagrammers with MSc’s. Most people here probably have no idea how ridiculous this world appears once you step out for a year or two and then take a look back in.
Everyone should: be computer illiterate, monolingual, never leave their home town, use left-pad, be regular illiterate, sedentary, uncultured, unlanded, and... alienated from their family?
Yes, everyone should explore the details of the technology they build on top of, and also should explore questions about what it means to be a person or how the world works.
The pursuit is performative and pretentious, in much the same way as body culture on Instagram. It’s about collecting achievements in an imaginary social game, and then bragging about it, while insisting that it’s not like that at all but some modern pathway to enlightenment.
To be clear, I’m not saying that people don’t genuinely achieve many of these things; they do. Many Instagram models also genuinely have spectacular bodies. It’s not about whether, but about why they are doing this, and the culture surrounding all of it.
Huh, I thought the thesis was going to be "... because it's a good learning experience everyone should do to understand how networking works" but the reason offered comes down to security. However, I'm going to go with what I had thought originally and actually make this an assignment for students. Anyone have experience witht that, could this be done in a semester?
My first job was at Westinghouse instrumenting a nuclear power plant. Our entire hardware-software package was a freebie given to the customer as part of a $200 million refueling contract (and that's in 1988 dollars). We, a team of 10, created a bespoke application stack which was effectively a web browser. The client machines were Sun 3 workstations. The server was some industrial mini computer that didn't have a TCP/IP stack - so we did in fact have to roll our own network stack.
Hah, the first engineering job I had was on Ovation DCS doing power plant controls. That system traces the lineage to the WDPF systems.
Was the server you mention here the actual DCS? With the Motorola CPU's? Running vxworks? Pretty cool recognizing something niche that is still, vaguely familiar. :)
The plant computer wasn't a DCS. I think it was a DEC. It gathered data from the control systems and instrumentation and had a bespoke in memory realtime-ish database. That database was then partially replicated down to the Sun workstations (code the 23 year old me wrote). Then the browser consumed that via a unix shared memory interface.
This article might be a bit tongue-in-cheek but it's actually something I've been thinking seriously about for a while. I can imagine a future where every country and company writes their own operating system and that might actually be a very good thing. There is a security advantage in not using popular technology stacks and rebuilding everything public-facing in-house. Because with Mythos-level AI capabilities, it is almost guaranteed that anyone with access to Mythos/Cyber can find a zero day in your stack. If your stack is proprietary and bespoke with no public access to source code it's much harder to find vulnerabilities, because they can only probe your public facing interfaces.
They won't be compatible with each other, guaranteed. Compatibility in reality comes from everyone using the same reference implementations that have been compatibility-tested, not from everyone implementing the same specifications.
I used to do this work in the IETF. take draft specs and write a C implementation and compare notes with the spec authors and other implementations. sometimes I would find a bug later on and see the same bug in multiple vendors implementations, and I would send them mail describing the issue and the fix.
its been very sad for me to see standardization get ignored, and the implementation become the point of reference. for a long time the only way to implement QUIC was to try to extract it from the Chromium code base - a pointless waste of time. but they spec for years was a couple of pages of meeting notes and a sample compression dictionary.
if we continue down this road we are impeding our own ability to evolve. if compatibility is defined by the implementation then were left with nasty balls of antiquated source that we carefully move around and try to plumb into our new environments, but no one really understands.
at the core, things like IP are very straightforward. we can and should specify the semantics of every bit, and have a wide variety of other implementations to test against. this provides a path for us to build new techniques and environments that are still useful in the world that exists today.
Monoculture. It's like when all bananas used to be clones of each other and a disease wiped out the whole species.
Used to be? Isn’t this still the case?
Oh yes, just a different cultivar
I would seriously recommend against building your own network stack for production use. Or writing your own web server for production use. Or database (whatever SQL or NoSQL) also for production use.
These sort of things are more complicated than you could expect and have plentiful pitfalls. Whatever you can do in reasonable amount of time is probably not that good compared to existing alternatives.
If you have actually pressing reason to build one and are ready and have means to spend time and effort on it go ahead. But carefully consider the effort needed...
I wrote my own web server for production use:
https://github.com/Qbix/webserver
I worked closely with Claude though
Claude wrote you a web server
holy shit. I was just tinkering with my production Laravel stack serving thousands in production trying to figure out how to improve worker concurrency (running out of RAM) and I encounter a random comment on HN which appears to solve my exact problem. This is so serendipitous
What is up with the README?
Meaning?
The real nightmare scenario is not just finding a vulnerability in the Linux network stack but finding vulnerabilities at the protocol level in TCP/IP itself or HTTP. That’s a problem that cannot be fixed. Has there ever been a precedent for this in computing?
why can't it be fixed? I assure you that linux has quite a rich history of network stack vulnerabilities. I found a ping of death about 10 years ago.
A while back I wrote an FPGA-based minimal network stack to work with the MRMAC hard IP of an AMD VC1902 with basically the same functionality: ARP, IPv4, ICMP Echo reply and UDP send/receive. I added the bare bare minimum to get UDP GRO working on the receiver side (Linux).
I also enjoyed the learning experience and works perfectly fine at up to 100G. But I definitely appreciate that I didn't have to go through the same pain under Linux where this stuff just works.
This is just an opinion and not a very sensible one at that. The Linux TCP/IP stack is one of the most scrutinized network stacks in the world and more than likely free of bugs that coud lead to a server takeover.
They thought QubesOS was secure but they found a trivial sandbox escape to root today.
Good to see that people still have this spirit of rolling their sleeves up and doing something like this for fun. Underneath it there is a very real point about mono-cultures and the increased magnitude of the impact of a risk, although more eyes checking one implementation should reduce the probability.
Everyone should build their own ** is the general advise I would give just about anything. Otherwise it is hard to appreciate how much effort it goes into things that we take for granted.
Everything looks simple from the outset until you try to build it yourself.
I recently saw this guy on HN who had written a web server for an Atmel AVR and also implemented a TCP/IP stack to boot. It obviously was far from feature complete, but it did work. He used SLIP to communicate with the "server."
Respect
We do these things not because they are easy, but because we thought they would be easy.
I also think there is an incredible transference of skills from one domain to another. This is a risk (everything looks like nail when you have hammer), but there are many domains that are very mature where you can learn a trick and apply it to a new domain over and over again.
At least look inside and appreciate the value of it already being together!
if you have time, money, energy, attention to do it then yes
but unfortunately not everyone have same opprtunities
My point is that it is a great way to learn and be more appreciative of what is done and why - network stacks, graphic stacks, web, etc - before being too critical of them.
Besides, statements such as "$7B for a proxy" or "it is just a wrapper" or "we can build it in-house" mostly come from those that have not had any measure of the scope due to not having any real experience with the said problem.
you can spend day less on HN and write something
or you can just do both ??? why we acting like HN isn't take 5 minute max ????
Cause it's not 5 min max
Back in the 8-bit days, we all wrote our own kernel process schedulers in order to make simple games. If you had an Apple II and wanted music, you'd need to make yours a hard real time one as well.
Prediction: as agentic code generation gets better, more and more code will be written JIT for it to be executed for security reasons. The engineer of the future is not only the one who uses agents to code, he uses agents to code each time "the" program is ran.
What's there to gain security-wise? Nondeterministic generation & then execution of that code without proper verification seems to be the opposite of a good security posture.
why are you assuming there would be no proper verification in this scenario?
Proper verification would be deterministic rules the JIT-ed code would be checked against, so it would have to be non-JIT. Since the comment is talking about using more & more JIT for security reasons, I assumed it extended to verification too.
I don't get why you'd generally switch to JIT for security reasons.
Why can’t you JIT- generate the code and then run the verification?
Because after proper verification you very much aren't at JIT territory. Take the network stack. From my memories a proper commercial test suit from say Defensics is from a few thousand to tens of thousand cases. For each of Ethernet, IP, TCP and UDP. Any decent coverage however fast will take some time. Most likely lot more than you want with just in time...
Yeah, the cost of running the test suite every time an agent generates code JIT would be the killer for running it at scale. I didn't even get into practicality of that approach too much because the gist of it for me was the question of agents writing code JIT having security benefits (?) - the verification thing is a sidetrack.
Certainly, adding agentic JIT code invites more complexity to properly do it, so what are the benefits that call for introducing it.
Where did I say you can't do that? I answered you why I assumed the original comment was leaning towards JIT for everything.
Ok so if it is indeed possible to verify the code after JIT generating it, I still don’t understand why you would assume that in the hypothetical scenario we aren’t doing that verification?
You literally said it can’t be JIT, I’m just saying it seems like it can.
Again, I answered that in the earlier reply:
> Since the comment is talking about using more & more JIT for security reasons, I assumed it extended to verification too.
I wouldn't consider feeding the JIT-ed code to a JIT-ed verifier code proper verification.
Even ignoring the verification bit, I don't see the security benefits of having agents write JIT code, hence the original question. Because there might be some edge cases I don't know about, but I can't see this applying generally.
Who writes the formal verification spec and when?
I suspect there are already plenty of test suites out there for something as universal as a networking stack.
Because the verification would also be done by something non deterministic and then that’s a paradox.
Feed the LLM output into a “deterministic” verifier, problem solved. That’s how LLMs verify their new mathematical proofs with lean.
If you're doing formal verification, why are you JIT generating Code? Is the formal verification also being JITd? How do you know the agent wrote a good spec?
I don’t know why, but it’s certainly possible to imagine JIT-generating code and then verifying it. Which is why I asked why we were assuming the verification wasn’t happening.
I doubt it. It seems far more likely that such code will be written just once by LLMs, but in a way that allows its claimed guarantees to be formally verified (e.g. in Lean). At that point there’s no need to JIT an implementation each time.
My bet is one ultra-hardened, minimal, front-facing system which does N-modular redundancy which N systems, each written on a different stack/different language.
The hardened software picks the computation that wins the majority.
It's not an issue to write all the implementations in the various stacks/languages: we'll have better and better LLMs to help us.
This shall bring security and shall allow to detect shitload of bugs (both in the implementation itself but also in the stack).
Heck, this could even be compatible with GP: one of the implementation could be JIT'e by a LLM, others could be written in advance (and Lean formally verified). Not sure which sense it'd make though.
I'm 99.9% sure it's coming for if it's not, I'll make one.
No
I disagree
So do I. According to today’s prevalent tech/science culture, “everyone” should
- write their own network stack, compiler, text editor, operating system
- learn 3-5 foreign languages
- travel extensively
- learn how computers work from the silicon principles to the userspace
- have a complete understanding of algorithms and data structures before even attempting to build anything, because nothing else will do
- read obscure Russian poetry
- “deeply” engage in 5-10 different philosophical practices and meditation techniques
- work out regularly, but according to strictly scientific principles, which you first have to research by reading a dozen books
- appreciate fine art, homestead food, and family life
Sorry folks, y’all are just Instagrammers with MSc’s. Most people here probably have no idea how ridiculous this world appears once you step out for a year or two and then take a look back in.
That's a great list actually.
Let's invert it.
Everyone should: be computer illiterate, monolingual, never leave their home town, use left-pad, be regular illiterate, sedentary, uncultured, unlanded, and... alienated from their family?
Well, I'm off to a great start!
Yes, everyone should explore the details of the technology they build on top of, and also should explore questions about what it means to be a person or how the world works.
What’s wrong with aspiring to do any or even all of those things? Those sound like nice things.
The pursuit is performative and pretentious, in much the same way as body culture on Instagram. It’s about collecting achievements in an imaginary social game, and then bragging about it, while insisting that it’s not like that at all but some modern pathway to enlightenment.
To be clear, I’m not saying that people don’t genuinely achieve many of these things; they do. Many Instagram models also genuinely have spectacular bodies. It’s not about whether, but about why they are doing this, and the culture surrounding all of it.
It was a joke if you read the article.
Glad to see you two read only the title, not the article; that fulfills the cliche.
And in your list you forgot taking a lecture in category theory.
Oh, the list wasn’t meant to be exhaustive. I also didn’t mention Homotopy Type Theory, Stoicism, and urban beekeeping.
Huh, I thought the thesis was going to be "... because it's a good learning experience everyone should do to understand how networking works" but the reason offered comes down to security. However, I'm going to go with what I had thought originally and actually make this an assignment for students. Anyone have experience witht that, could this be done in a semester?
Much more fun on microcontrollers!
Looks at frankly staggering number of CVEs made by people missing some edge case in networking
"Please don't"