The Packet Pushers share perspectives on job interviews. They talk about how to prepare, discuss the what an interviewer is really thinking, and offer tips on getting ready for the technical and non-technical portions of the interview.
The post Show 263: The Job Interview Process appeared first on Packet Pushers.
Contrary to folk wisdom, ignorance is usually not blissful. Generally, it produces the very opposite of bliss. Just ask the frightened hiker lost in some remote mountain blizzard who never paid attention to his Boy Scout instruction; or ask the new employee who never did her math homework, frantically trying to figure out the correct change for customers; or, worse yet, ask the frustrated and annoyed patrons waiting in the ever-increasing line as this new employee bumbles one purchase after another.
Phillip Dow, Virtuous Minds
The post QOTW: Ignorance appeared first on 'net work.
The post Worth Reading: The Cryptech Project appeared first on 'net work.
Please join us in congratulating the following iPexpert students who have passed their CCIE lab!
One of the key decisions in designing a compute infrastructure is how to handle networking.
For platforms that are designed to deliver applications, it is now common knowledge that application developers need a platform that can execute and manage containers (rather than VMs).
When it comes to networking, however, the choices are less clear. In what scenarios are designs based on single layer preferable vs. overlay networks ?
The answer to this question is not a simplistic one based on “encapsulation overhead”; while there are overlay networking projects that do exhibit poor performance, production ready solutions such as OpenContrail have performance characteristics on both throughput and PPS similar to the Linux kernel bridge implementation. When not using an overlay, it is still necessary to use an internal bridge to demux the container virtual-ethernet interface pairs.
The key aspect to consider is operational complexity!
From a bottoms-up perspective, one can build an argument that a network design with no encapsulation that simply uses an address prefix per host (e.g. a /22) provides the simplest possible solution to operate. And that is indeed the case if one assumes that discovery, failover and authentication can be handled completely at the “session” layer (OSI model).
I’m familiar with a particular compute infrastructure where this is the Continue reading
Imagine you’d design your network by documenting the desired traffic flow across the network under all failure conditions, and only then do a low-level design, create configurations, and deploy the network… while being able to use the desired traffic flows as a testing tool to verify that the network still behaves as expected, both in a test lab as well as in the live network.
Read more ... Slowdown aside, Cisco CEO Chuck Robbins says he is optimistic for next year.
I wanted to call out a couple of software packages whose vendors I’ve worked with recently that I felt had really good customer service. The software packages are BusyCal (from BusyCal, LLC) and Textual (from Codeux Software, LLC).
As many of you know, the Mac App Store (MAS) recently suffered an issue due to an expired security certificate, and this caused many MAS apps to have to be re-downloaded or, in limited cases, to stop working (I’m looking at you, Tweetbot 1.6.2). This incident just underscored an uncomfortable feeling I’ve had for a while about using MAS apps (for a variety of reasons that I won’t discuss here because that isn’t the focus of this post). I’d already started focusing on purchasing new software licenses outside of the MAS, but I still had (and have) a number of MAS apps on my Macs.
As a result of this security certificate snafu, I started looking for ways to migrate from MAS apps to non-MAS apps, and BusyCal (a OS X Calendar replacement) and Textual (an IRC client) were two apps that I really wanted to continue to use but were MAS apps. The alternatives were dismal, at best.
Raging Capital's raging has partially paid off.