6

What works for you might not work for me

 3 years ago
source link: http://rachelbythebay.com/w/2013/06/12/learn/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

What works for you might not work for me

I occasionally get requests for advice regarding how to learn something or other. This is actually a difficult question to answer, since everyone has their own way of integrating new information. I'm talking about actually getting to the point where you understand something inside and out and just don't parrot it back.

The best I can usually do is relate some tales about techniques which have turned out to be effective or someone I know. The idea here is to hopefully let the listener figure out if they're like me, or like the other people I might describe, or not at all. Of course, if they don't yet know what to look for, then that becomes the immediate problem to solve.

In that case, I would suggest picking something arbitrary and then following it along for a while to see if it starts making sense. If not, then there's probably some mismatch between you and it and you might want to try something else. This is the basic principle of "pick something, anything, even if it turns out to be wrong" which can be heard in the realms of startup circles and minimum viable products. It seems to apply here.

One thing I find which helps when trying to crack something difficult is to keep good notes. Just a running commentary of things which have been done somehow makes it work out better. I'm not sure if it's because the act of turning internal state into words gets more of my brain involved, or if perhaps reading it back to proofread things also gets more gears turning, but something good happens there.

Maybe it's like being lost in the woods. If you don't know where you've been, then how do you know if you're going in circles? Working on technical problems seems to be a lot like that. I'm pretty sure that I'd wind up going in circles if there were too many options and no clues as to which ones would turn out to be useful.

Let's say someone came up to me and asked how to learn about networking. The answer I know best is the one which happened to work for me: mess around with raw packets on a quiet Ethernet. If having a goal is helpful (and for me, it definitely is), then think about what it would take to have a totally-local chat system which ran without IP addresses.

It doesn't make a whole lot of sense now, but back when I was playing with this stuff, it did, since most of the machines I could use only ran DOS. That meant they didn't have an IP stack. The only IP stuff you could do was basically an outgoing telnet, and while that was running, the host could be pinged and also had a rudimentary FTP server. Nothing else could be done.

In that sort of environment, being able to just drop a packet on the wire by way of the network card's driver (the "packet driver") was about the only way to go. It was simple enough to send something to FF:FF:FF:FF:FF:FF and have everyone else listen for it. Most of the hosts would ignore it, and those which happened to be running my little chat program would display it. Then they could respond in kind.

Obviously, you wouldn't want to do this sort of thing in any real quantity. Polluting the network with tons of broadcast packets is a great way to get a visit from your local BOFH. Just look at what happened when the first release of DOOM landed in 1993, and with it, an all-broadcast IPX network scheme. What a mess!

Now, by using broadcast datagrams, it meant there was no opportunity for error correction or retransmits other than taking the NIC's confirmation as the truth, but it was a start. It was code like this which later grew into some other projects which I have described in some older posts.

Today, I wouldn't advise quite the same thing, if only because raw Ethernet access is actually more difficult than it used to be. Sure, you can open a raw socket on most machines, but now you're talking about running "learner code" with privileges -- scary! I would think that using broadcast UDP packets would work just as well for demonstration and learning purposes, and they wouldn't cross any routers, either.

Then again, maybe this is changing. With some of these newer tiny embedded systems which are intended for exploration coming out, perhaps it will be easy to throw bytes right on the wire again without worrying about hosing the device.

It took a lot of bit slinging to build up a model of how my network might be doing its thing. Still, that's just what worked for me, and the last thing I expect would be for it to work for everyone else.

I think we can do better than "one size fits all".


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK