Rendered at 20:34:11 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
intrasight 9 hours ago [-]
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.
RealityVoid 8 hours ago [-]
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. :)
intrasight 5 hours ago [-]
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.
Ekaros 7 hours ago [-]
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
matltc 6 hours ago [-]
What is up with the README?
EGreg 5 hours ago [-]
Meaning?
inigyou 4 hours ago [-]
Claude wrote you a web server
andai 8 hours ago [-]
Monoculture. It's like when all bananas used to be clones of each other and a disease wiped out the whole species.
tmountain 8 hours ago [-]
Used to be? Isn’t this still the case?
jaennaet 7 hours ago [-]
Oh yes, just a different cultivar
znnajdla 6 hours ago [-]
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.
fc417fc802 18 minutes ago [-]
This is the same erroneous reasoning as historical claims that FOSS was less secure due to being public. That has been disproven many times over by now.
The only way it might hold here is if no one with access to the cutting edge models bothers to run your code through one while an adversary does. That seems highly unlikely, particularly for any well funded organization.
That said I agree that monoculture is bad. Vulnerabilities like heartbleed or spectre are so devastating precisely because they apply to approximately everyone.
inigyou 4 hours ago [-]
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.
convolvatron 3 hours ago [-]
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.
Hoftheater 8 hours 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.
znnajdla 6 hours ago [-]
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?
toast0 48 minutes ago [-]
When these things come up, what usually happens is implementations stop following the spec as written.
Many issues can be handled with minimal coordination, but some things work much better with consensus and you see flag day campaigns. Ipv6 flag day had very limited impact on that day, but may restarted the process and actually got things moving. DNS flag days have been successful.
3 hours ago [-]
hn_submit 7 hours ago [-]
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.
inigyou 4 hours ago [-]
They thought QubesOS was secure but they found a trivial sandbox escape to root today.
znpy 2 hours ago [-]
Yeah, it’s well known that you can prove the presence of bugs but you can’t prove their absence.
All software is to be considered insecure, formally speaking.
amoss 10 hours ago [-]
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.
_pdp_ 8 hours ago [-]
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.
hn_submit 7 hours ago [-]
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."
utopiah 1 hours ago [-]
> far from feature complete, but it did work
well that's the trick. If you look at implementing a Web browser or a physics engine you instantly give up, and you are right about it, it's just too hard. If instead you write a partial HTTP client which can display some text from a URL or have a 3D scene and in it an object Y coordinates get smaller each millisecond then suddenly in terms of the essence of each, you are 80% there really. Now if you want to implement the "rest" you might need an entire lifetime, or more. Still IMHO it's definitely worth doing very compact and limited versions of all those in order to learn, even if done only once in your life.
convolvatron 40 minutes ago [-]
I used to implement these things professionally and to write an IP + TCP + HTTP is certainly less than a year with experience. would I ship that and expect people to use it without a lot of burnin? no..but to say that its a lifetime of work is off by at least a factor of 10.
_pdp_ 7 hours ago [-]
Respect
Hasz 7 hours ago [-]
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.
DANmode 7 hours ago [-]
At least look inside and appreciate the value of it already being together!
tonyhart7 8 hours ago [-]
if you have time, money, energy, attention to do it then yes
but unfortunately not everyone have same opprtunities
_pdp_ 8 hours ago [-]
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.
PunchyHamster 8 hours ago [-]
you can spend day less on HN and write something
tonyhart7 8 hours ago [-]
or you can just do both ??? why we acting like HN isn't take 5 minute max ????
tipperjones 5 hours ago [-]
Cause it's not 5 min max
rbanffy 8 hours ago [-]
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.
dromologist 9 hours ago [-]
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.
mihaelm 9 hours ago [-]
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.
daishi55 9 hours ago [-]
why are you assuming there would be no proper verification in this scenario?
mihaelm 9 hours ago [-]
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.
daishi55 8 hours ago [-]
Why can’t you JIT- generate the code and then run the verification?
Ekaros 7 hours ago [-]
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...
mihaelm 7 hours ago [-]
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.
mihaelm 7 hours ago [-]
Where did I say you can't do that? I answered you why I assumed the original comment was leaning towards JIT for everything.
daishi55 7 hours ago [-]
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.
mihaelm 7 hours ago [-]
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.
patmorgan23 8 hours ago [-]
Who writes the formal verification spec and when?
daishi55 7 hours ago [-]
I suspect there are already plenty of test suites out there for something as universal as a networking stack.
compounding_it 9 hours ago [-]
Because the verification would also be done by something non deterministic and then that’s a paradox.
daishi55 7 hours ago [-]
Feed the LLM output into a “deterministic” verifier, problem solved. That’s how LLMs verify their new mathematical proofs with lean.
patmorgan23 8 hours ago [-]
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?
daishi55 8 hours ago [-]
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.
p-e-w 9 hours ago [-]
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.
TacticalCoder 9 hours ago [-]
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.
fc417fc802 27 minutes ago [-]
I feel like that idea is erroneously mixing concepts. You want quorum in safety critical contexts, generally to guard against hardware failure. I think using independent implementations in such a scenario is uncommon and to date largely a stop gap to save money by replacing formal verification.
For security formal verification is really what you need. Both of the software and also eventually the hardware, since typically formal verification of software won't hold up against something like rowhammer. (Although TBF I'm not sure what sort of formal verification would have caught rowhammer.)
dakolli 8 hours ago [-]
No
N_Lens 9 hours ago [-]
I disagree
p-e-w 9 hours ago [-]
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.
andai 8 hours ago [-]
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!
patmorgan23 8 hours ago [-]
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.
GPerson 8 hours ago [-]
What’s wrong with aspiring to do any or even all of those things? Those sound like nice things.
p-e-w 6 hours ago [-]
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.
adamddev1 9 hours ago [-]
It was a joke if you read the article.
sva_ 9 hours ago [-]
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.
p-e-w 8 hours ago [-]
Oh, the list wasn’t meant to be exhaustive. I also didn’t mention Homotopy Type Theory, Stoicism, and urban beekeeping.
ModernMech 7 hours ago [-]
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?
convolvatron 1 hours ago [-]
I did this for a couple years at University of Washington. We did IP, TCP, RIP, forwarding and a couple other things. they weren't compatible with the actual RFCs- they were kind of stripped down to the bare essence. I wrote the sample and the tests, and then I ripped out the guts and presented them with a shell, went over the protocol in lecture and provided a kind of spec for them to implement.
the parts I was most proud of was (a) your score was directly related to the number of tests passing, so you know in advance what your score would be and could decide how much effort. (b) every assignment came with a relevant visualization that showed things like the routing table as a directed graph, or the TCP sequence diagram. I was available in the lab for a good 2-3 hours a day on weekdays to answer questions.
I think some of the students got a pretty good picture of how things worked, but the overwhelming opinion was that it was just too much work. a lot of the students just copied off each other. we also had quarters, so ...
contingencies 9 hours ago [-]
Much more fun on microcontrollers!
PunchyHamster 8 hours ago [-]
Looks at frankly staggering number of CVEs made by people missing some edge case in networking
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. :)
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...
https://github.com/Qbix/webserver
I worked closely with Claude though
The only way it might hold here is if no one with access to the cutting edge models bothers to run your code through one while an adversary does. That seems highly unlikely, particularly for any well funded organization.
That said I agree that monoculture is bad. Vulnerabilities like heartbleed or spectre are so devastating precisely because they apply to approximately everyone.
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 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.
Many issues can be handled with minimal coordination, but some things work much better with consensus and you see flag day campaigns. Ipv6 flag day had very limited impact on that day, but may restarted the process and actually got things moving. DNS flag days have been successful.
All software is to be considered insecure, formally speaking.
Everything looks simple from the outset until you try to build it yourself.
well that's the trick. If you look at implementing a Web browser or a physics engine you instantly give up, and you are right about it, it's just too hard. If instead you write a partial HTTP client which can display some text from a URL or have a 3D scene and in it an object Y coordinates get smaller each millisecond then suddenly in terms of the essence of each, you are 80% there really. Now if you want to implement the "rest" you might need an entire lifetime, or more. Still IMHO it's definitely worth doing very compact and limited versions of all those in order to learn, even if done only once in your life.
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.
but unfortunately not everyone have same opprtunities
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.
I don't get why you'd generally switch to JIT for security reasons.
Certainly, adding agentic JIT code invites more complexity to properly do it, so what are the benefits that call for introducing it.
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.
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.
For security formal verification is really what you need. Both of the software and also eventually the hardware, since typically formal verification of software won't hold up against something like rowhammer. (Although TBF I'm not sure what sort of formal verification would have caught rowhammer.)
- 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.
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!
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.
And in your list you forgot taking a lecture in category theory.
the parts I was most proud of was (a) your score was directly related to the number of tests passing, so you know in advance what your score would be and could decide how much effort. (b) every assignment came with a relevant visualization that showed things like the routing table as a directed graph, or the TCP sequence diagram. I was available in the lab for a good 2-3 hours a day on weekdays to answer questions.
I think some of the students got a pretty good picture of how things worked, but the overwhelming opinion was that it was just too much work. a lot of the students just copied off each other. we also had quarters, so ...
"Please don't"