Indeed! This book is likely to be 100x more interesting than your local college's undergrad networks course.
The dozen or so principles Varghese lays out for writing fast networking code is reason enough to pick it up. The writing is very approachable, too. Reminds me more of the early network operator books than a CS text.
Don't be too discouraged by job postings requiring an EE or CE degree. At my last two companies (a network gear vendor and a hosted VoIP provider), our postings stated EE/CE was preferred for new grads, but what we really needed were folks with systems programming experience and an understanding of the SW/HW interface.
If you've internalized most of your systems classes (OS, computer architecture, compilers, networks, etc) and are comfortable mucking around in C/C++, you're no worse off applying for these jobs than most new EE/CE grads.
Thanks, this is particularly useful information as I have a growing interest in all things embedded. My experience at this point is pretty minimal and is limited to messing around with an Arduino which, as I understand from reading about bare-metal AVR programming, is fairly high level by comparison. How does that translate with what people in the industry are using?
At Tesla we have lots of embedded software opportunities, ranging from code that runs in very tiny microcontrollers to beefy ARM host processors. If you, or anyone else in this thread, are interested, contact me on email. My inbox at Tesla is sbrugada.
Nothing sexual was implied by my comment, though I do see how the word is problematic. "Seminal" is so frequently used to describe early and influential bands in punk, including Riot Grrrl, that the etymology is rarely considered.
A great talk if you have 40 minutes to spare, here is a summary for those that don't:
- the networking community has backed itself into a crufty transition that will involve a ton of NATs and ALGs due to the deferment of v6 roll-outs by incumbent carriers.
- v4 space will run out in different regions at different times, leading to disparate and hastily constructed transition solutions.
- this is going to break end-to-end in a very bad way.
- last mile telcos and cable operators do not want to invest in equipment required to make this work at the edge.
- they'll probably try to extort content/application providers into funding the transition.
- and/or erect a service model where your end-to-end connectivity time is metered, i.e. your v4<->v6 NAT is time limited.
- government regulators need to step in to avoid a fragmented Internet
The trouble is, you'd have an easier time selling the scraps of your lunch than you would a home in Vegas. Condos that were going for $180K in my old neighborhood are now at $30K and still going down. It's going to be a looong time before the city recovers.
While I don't argue with the title of the article - bandwidth caps really are just a way to deal with infrastructure costs by passing it on to some consumers - the use of IP transit as a reference for an ISPs cost of service is inaccurate.
IP transit costs are what a carrier or ISP would pay to get traffic from their main datacenter/CO in a given metro area to the Internet. This is an operating expense and is a drop in the bucket compared to CapEx they spend on the last mile.
The cable operators and mobile carriers are freaking out because they are constantly pouring money into nodes splits and QAM carriers(cable) or radios, backhaul, and spectrum(mobile). These are the real money pits of their businesses and their motivation to enforce data transfer caps, throttling, etc.
Backbone capacity is not nearly as big of an issue, despite traffic growth. Long haul DWDM systems get denser, higher bit rate transponders get built, etc to push more bits across the same fiber.
Whoever can pay to lease a conduit would have access to it, I'd imagine. The company that leases the conduit would be responsible for buying the glass, pulling it, and splicing it. I imagine a contractor would be selected to repair and maintain the conduit in the event of back hoe.
Power companies and some telecoms do this now for "pole rights" on aerial fiber/copper builds.
The dozen or so principles Varghese lays out for writing fast networking code is reason enough to pick it up. The writing is very approachable, too. Reminds me more of the early network operator books than a CS text.