A student’s mind is like a blank slate. What you teach them is what they write in that slate and this is why one should not misguide them by teaching, it is better to admit that you do not know something rather than leading them down the wrong path. – A Mathematics Professor
Failure is not something that is new to me, and to me failure has been a great
teacher in ways of how NOT to do things. But that is not what upsets me in
this specific case, let me elaborate.
The NetBSD board finally got back to me regarding the project and it was quite
clear that I did not jackshit about what I wrote up and it is not too far from
the truth.
Also there are a lot of N/F and ? entries in your API matching table, and
from the proposal it is not clear how fammiliar you two are with the
internals of the NetBSD networking stack.
I should have followed my gut instinct here and should have looked into easier
projects to pick up to gain experience instead of embarking on a fool’s quest on
doing something like porting the entire wireguard protocol into NetBSD. Not
because the task is impossible but the sheer lack of my experience in writing
kernel code.
Just FTR I’m not actively part of the proposal. I’m purely involved in an
advisory capacity.
This along with the rather hand-wavy support from cherry@ along with his
obsession about not using “kernel module” to write up the wireguard interface
was not helping me. Even though I managed to export a kernel module to
userland[1] for writing up ATF tests, this was apparently not good enough for
him to point me in the right direction for wireguard.
Even at advisory capacity, the incompetence was beyond comprehension. And by
this I do not mean I intend to be carried[2] by cherry@ in this project. A
simple technical review of the proposal by cherry@ did not find the obvious
blunders in the technical details I put forward in the proposal. An advisor even
in the least of the capability should be able to point out what seems to be
obviously wrong and in worst case admiting that they are not qualified to advice
on the topic instead of giving me tips and tricks on how to improve my english
grammar in the proposal.
I think there is a lot of communication gap in what I intend to do and tasks
assigned by cherry@. More over his lack of interest in doing systems programming
is showing, which is an understandable when one has worked on these things as
long as someone like cherry@ has especially when it is driven by a need for
survival than a pursuit of passion.
After further discussion with cherry@, we came up with a statement…
Please give us a bit more time - until the end of June, to start on the
research for this. At this point I will personally have finished up on the
x86 stuff as well and will have more headspace. Sorry for going quiet, and
no, we hadn’t dropped the ball.
Personally I think we have lost the edge in trying to port WireGuard to BSD,
despite the ground work I laid out towards the end of 2017. And it looks like it
is only going to get worse before someone else picks up the slack and finishes
this.
In conclusion I see this as my failure to grasp the underlying complexity of
systems programming. A field dedicated to create abstractions between hardware
and software so that idiots like me can type things like this into a file
without ever knowing the intricate details and behind the scenes of how a file
is being opened or maintained in memory, not to mention the plethora of things
happening from capturing my key strokes, displaying them on screen and saving
them to a disk.
I am not driven to poke into operating systems as means of survival, instead I
am passionate about computers in general. As a person who likes to poke around
and get to know how things work, systems programming is the way to go, it is not
an easy path from what I hear, but later in life when I look back this may have
been a struggle that is worth fighting for.
References
- https://github.com/fraggerfox/rperm-netbsd
- https://www.urbandictionary.com/define.php?term=Carried