Building my own network stack(blog.lyc8503.net) |
Building my own network stack(blog.lyc8503.net) |
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 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.
> 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.
But since AI models are non-deterministic and the harness matters a lot, simply "running your code through one" doesn't guarantee you'll find all the zero days. An attacker can simply run a few more iterations or use a slightly more advanced harness, or increase the temperature level and they are likely to find zero days which the maintainers didn't.
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.
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...
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 ...
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.
This is a far cry from an actual network stack.
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.
- 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!
And in your list you forgot taking a lecture in category theory.
"Please don't"
The exact same line of reasoning applies to human security researchers and pen testers as well. The only difference is that automated testing via frontier models is affordable even for individuals.
The VM comment is total nonsense. That's only going to be the case for an extremely short period here until the major projects all adapt their release procedures to include automated security audits. I imagine the kernel as a whole and KVM in particular will begin receiving a huge amount of such attention. I also expect increasing amounts of such load bearing code to be formally verified as the primary barrier to that has always been the amount of human time required.
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.)
And additionally, TCP/IP was an optional layered product - either DEC's own UCX (Ultrix Communication eXtensions) or 3rd party
I remember working with this engineer writing in the lower level TCPIP stack on the deck - maybe in Fortran? Anyway, he didn't understand why he wasn't getting all the data transmitted and while I was no expert in TCP/IP, I was already familiar with packets and maximum segment size (MSS). I remember being impressed that he banged out a network stack in a couple weeks.
My point is that the essence, the core mechanism, is typically a 1-liner, but only with a pedagogical context, not a production (in the sense of anybody else using it reliably in realistic situations) context.
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.
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.