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. :)

...what kind of credentials did you have to become a hw/sw engineer at a nuclear power plant as your first job?

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.

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.

Used to be? Isn’t this still the case?

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.

Yes, lots. Early spdy was vulnerable to CRIME attacks and so was TLS1.0 (and to bunch of other attacks). Kaminsky DNS cache poisoning is another one that comes to mind

Many: OS detection (ICMP, IGMP, ARP, TCP, etc.), topology disclosure (ICMP), DoS (many early protocols did not perceive resource exhaustion in their threat model; a prominent example being SYN floods / TCP half-open), etc.

Are you aware of the syzkaller and how many bugs it still finds including in networking stack?

They thought QubesOS was secure but they found a trivial sandbox escape to root today.

lols, what about the sendfile and other vulnerabilities that lasted decades. Linux just does not have a secure mentality, it has a hacker mentality, maybe acceptable for a lot of uses, but it is what it is.

Wanting to incorporate an http server into a C project of mine, the only battle-tested or feature-complete options either allocated dynamic memory UTH without an option to override the allocators, or are too opinionated with the core API, like mandating callbacks for everything. Suprisingly there's no decent (single header) C library that don't have these 2 issues, at least that I could find.

I wrote my own web server for production use:

https://github.com/Qbix/webserver

I worked closely with Claude though

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.

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

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.

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.

No

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.

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 ...