wrong tool

You are finite. Zathras is finite. This is wrong tool.

  • Email
  • LinkedIn
  • RSS
  • Twitter

Powered by Genesis

Rain Drops and Rivers in Network Firewalls

October 9, 2014 by kostadis roussos Leave a Comment

One of the funnest parts about having a job in a industry you know nothing about is that you can ask really basic questions. Those questions allow you to build mental models that you can then use to learn about an industry and perhaps if you are extraordinarily lucky and pick the right time and place make an impact on an industry.

What follows are really basic insights, nothing profound here…

When I looked at Firewalls, the networking part of the firewall was very mysterious. Most of the value was in security, but a lot of the hard-back-breaking work was in integration with the network. Especially at scale the network integration was extraordinarily important.

At first I thought it was about protocols. And there is some truth to that but a lot less than we all think. The need to integrate in line with thousands of protocols is absolutely a challenge and a barrier to entry but not the real source of the challenge.

Maybe a different way to express my comment is that the protocol integration challenge is a signal that there is something going on there that is causing complexity, protocol integration is a symptom not the cause.

And my latest way to express the problem is the following:

If you imagine an IP network it’s a flood of packets like raindrops falling from the sky. And at every hop, decisions are made on a per-packet basis.

But security can not be implemented on a per-packet basis. You have to look at a large number of variable packets. The more complex the security system, the more packets that need to be looked at.

The challenge with firewalls is that you need to turn the flood of packets from millions of Alice’s, into little streams of packets that you can then inspect and once done inspecting flip that stream around into packets that the millions of Bob’s are expecting and send them out. Later on you have to be able to get packets from a specific Bob and correlate that packet with packets you received from a specific Alice talking to that specific Bob , turn Bob’s packets into a stream, inspect the packets and send the packets back out to the right Alice.

And – oh by the way – Alice and Bob must never know that you did that because the protocols may not allow that.

I have this image of water drops coming in one end, you enter the firewall and they turn into streams, and then they leave the firewall as raindrops the other side. And this image is remarkably resilient to explaining many things about how firewalls work and why some things in firewalls are easy and somethings are very hard.

And the nice thing about this model is that it explains why protocol processing is so crucial … without the ability to process a protocol it’s impossible to make the rain drop to stream to rain drop transformation correctly and because you are looking at all of the rain drops trying to find a bad guy, protocol completeness is crucial – skip a protocol and that is the door way for the bad guys.

 

 

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: Security

Impressed with Yahoo Mail

October 5, 2014 by kostadis roussos Leave a Comment

Over the weekend, I decided to finally wrest control from the crap in my Yahoo Inbox. Because of my willingness to sign up for any service, my inbox had escalated from a small number of emails to over 18k unread emails since 2009!

Yahoo’s decision to give unlimited space made this worse, the caps on storage would periodically force me to get a handle on things, and now … well … now the Inbox could just grow and grow and grow…

Given my Inbox dates from pre 2000, more or less when yahoo mail started, this exercise filled me with wonder. Would Yahoo still be able to serve up my email? Would I find curious pauses in my email as I scanned further and further back in time? Would email just disappear? Would those emails from 1999 be gone?

Turns out that Yahoo handled my searches through time wonderfully. And more importantly I was able to find some memorable old emails from my friends from almost 15 years ago.

My inbox was probably initially served off of the original infrastructure that Yahoo made available to customers in the 1990’s. To see the data still being available was impressive. Being able to store and retrieve 15 years of email correctly, given the data center migrations, storage system upgrades, infrastructure upgrades, CEO turmoil is a tribute to the quality of the engineering team at Yahoo.

 

 

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: Random Fun

First picture on iPhone

September 30, 2014 by kostadis roussos Leave a Comment

IMG_0001.JPG

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: Uncategorized

Am an Appearance Conscious Asshole

September 30, 2014 by kostadis roussos Leave a Comment

No longer a Technology Conscious Prick

Just bought my first iPhone (iPhone 6 plus) after years of Android.

Not clear if I am delighted yet.

Scheduled some time with a stylist …

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: Uncategorized

Lambda C++

September 27, 2014 by kostadis roussos Leave a Comment

After a large time gap between large C++ systems, been catching up on the language. Feels like meeting a high-school friend who you didn’t friend on Facebook.

One of the things that got me to realize that this was not my childhood’s C++ was the existence of lambdas.

At first, I was like: EWWWW… First we had Java envy and now we have Scala envy… does anything ever change.

Except now that I am starting to dig into this little feature, the fact that you can write this piece of code is wicked convenient:

vector<int> v;
v.push_back( 1 );
v.push_back( 2 );
//...
for_each( v.begin(), v.end(), [] (int val)
{
    cout << val;
} );

My personal frustration with using STL may be finally overcome…

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: Software

The real story behind net-neutrality?

September 22, 2014 by kostadis roussos Leave a Comment

There is a lot of dialogue about net-neutrality, what isn’t really discussed is this problem:

Jeff Reading, a communications director for Mayor Ed Murray, told MyNorthwest.com that the city wants people to limit their “non-essential mobile conversation” so that cell networks can stay unclogged in case of emergencies.

Basically the mobile internet was not built to handle video and the huge volume of images that we’re creating.

Everyone involved in creating rich media applications knows this or should…

There is a debate raging over how do we pay for the necessary infrastructure upgrade.

This is a classic IT vs Business Group debate with no CEO in charge to make a decision. In a traditional company the business team wants something out of IT, and IT is happy to provide as long the business group provides the budget … These debates go on for months until someone either finds another way to solve the problem or someone caves.

In a more socialist country, the state would just foot the bill and we would have better pipes. In our less socialist country, corporate entities argue amongst themselves and appointed officials make decisions based on interpretations of the law that result in further litigation that ultimately result in someone paying the bill…

The basic problem is the following:

  • The content management companies and content distribution companies want to force IT to pay for the bill from their budget
  • IT wants to get a piece of the action and wants the content management businesses to pay more for the infrastructure build out.

And billions of dollars of wealth for the owners and senior managers of those companies are at stake. This will take a while to resolve. The infrastructure build out to support the new network is going to be colossal. We are going to need new handsets, towers, gateways and backbones and all of that is going to be very expensive to replace and upgrade.

The one company that is taking an orthogonal point-of-view to this debate is Google. Google is basically telling IT: Screw you… if you won’t build it we will… And so we have Google Fiber.  And Google’s action may force traditional IT to pay for the upgrade through internal operational optimization rather than new sources of revenue … Proving to me, at least, Google is one of the most interesting companies on the planet.

 

 

 

 

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: Net Neutrality, Selling

Was a technology conscious prick

September 20, 2014 by kostadis roussos Leave a Comment

http://www.theonion.com/articles/iphone-6-plus-vs-samsung-galaxy-s5,36969/

Now planning to become appearance conscious asshole.

 

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: Random Fun

Debugging an archaeological find

September 20, 2014 by kostadis roussos Leave a Comment

When confronted with a bug in a piece of software whose authors are lost in the mists of time, and whose internal workings are opaque and mysterious, debugging can be a challenge.

But that’s why we became engineers, we like challenges.

The first problem is to understand what the nature of the bug is. Typically you get some crash that has a signature that suggests that something went wrong in the machinery of the ancients.

Our first reaction, because we are human is to cry out:

That’s not true. That’s impossible!

How can the machinery of the ancients be broken? It never breaks!

The first challenge is to understand the nature of the breakage. Sitting in a sea of memory with no clue what is going on…  you have to begin the process of sifting through the code and the memory to understand what exactly has happened. Not what the bug is, but what the sequence of events that occurred that produced a crash.

The goal is to create a hypothesis that explains how the crash occurred, not the why, but the how.

There is one strategy that is interlinked. The first part is to start reading code and analyzing core files, and looking to see if similar bugs got reported in the past and got swept under the rug. The second part is to desperately and frantically try and reproduce the bug.

Essentially what you are trying to do is gather experimental evidence to guide the analysis of the software and the ancient bug reports.

Once you have figured out how the bug occurred eg: memory got corrupted and that resulted in this set of instructions to execute, the next step is to begin the process of how.

This turns out to be both trickier and easier. Easier because you now know how the crash happens. Trickier because you know need to understand an increasingly larger scope of the system …

In the case of corruptions there are at least two possibilities: structural or wild.

A structural corruption is caused by the code that manipulates the data structure … This is easy because the problem is localised.  Tricky because as an archaeoligst you may need to go several layers away from where the crash occurred requiring more analysis to follow the code all the way to the source of the flaw.

More inelegantly, there is a core data structure that is busted, there are other data structures that are related to that data structure, either as inputs or as outputs, being able to see how the dependent data structures look as compared to the corrupted one can guide your investigation. You are looking for the source of the corruption and seeing the input and output data structures can tell you where to start looking depending on their state. Sometimes there are no input and output data structures, just lots of dependent ones but the principal holds.

In this case you want the testing to get narrower and narrower to find the bug faster and in a more focused way. As you get a better understanding of the code and the processes and the internal data structures the testing goes from being – use a thermometer to use an MRI…

Wild corruptions are caused by two unrelated pieces of code causing each other harm. Some random piece of code is causing the ancients code to get fubar’ed. And if the code is vast and large, understanding where that can happen can be hard but not impossible. To attack that problem you a useful approach is to do a brute-force attack on the code to see what combination of features executing in parallel or in isolation can cause the bug. Your goal is to find the places that are running and see how you can find the one piece of code that is doing the wrong thing. This is why reproduction of the bug remains the single most important process in debugging archaeology.

The nice outcome of this process is that in the end the understanding of the mysterious ancient technology is revealed. And with that comes a moment of personal satisfaction. You are now one with the ancients.

And then a desire to rewrite their code overcomes you… and then you too become a new ancient one….

 

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: Debugging, Software

Software Archaeologists

September 17, 2014 by kostadis roussos Leave a Comment

2014-09-16_2231

Work at a large company with a massive code base that has evolved over many years, and you eventually have to engage in Software Archaeology.

Software archaeology is the process of trying to understand critical software systems that are poorly documented, poorly understood or not understood at all and super-critical to your  system.

Imagine you have some module that you are dependent on that has worked for years, and then a bug is uncovered.

You have to go and learn what exactly the module does. By the time you look at the code, the original authors, and their children have all left the company or even if they haven’t its been years since they worked on the code… Sometimes it’s been years since they looked at code period, now being managers or directors or vice-presidents…

At times you can feel like you’re one of those modern explorers violating some tribal rules by exploring in areas that are forbidden. And if you have to modify the code, you wonder if you are like Indiana Jones about to remove the gold idol…


The problem isn’t understanding the structure of the code, software is software. The problem is understanding the intent of the code: understanding where choices were made that were well reasoned, and where choices were made that were expedient. And the problem isn’t even the software that you have to inspect, but that it’s part of a broader sea of software that the ancients wrote that is equally opaque and mysterious.

And the real problem is that static analysis is fine, but what you really need is to understand is how the running system behaves. How it uses memory, how it uses the CPU, how the data structures grow and shrink, what the heart beat of the system is…

At SGI in the late 90’s I did some compiler research as a master’s student to try and address this specific problem. In particular how do you infer things like locking hierarchies in a multi-million line code base when the original authors of the code have since left? Just reading the code is insufficient. Knowing that locks are taken is important, but you also need to understand things about contention, frequency of locks, interplay between systems that are so widely split apart to be mysterious …

When I tried to solve the problem, I looked at using compilers to go and insert code everywhere where something looked like a lock and then use the testing infrastructure to find the locks and their hierarchies…

And then I discovered that the code of the ancients because it was always working has no tests.

Doing your run-time analysis involves figuring out how to test things that always worked. And then you uncover not just one bug, but hundreds… Or are your tests broken because you don’t understand the code… And you wonder as you play with this mysterious gadget… Are you about to destroy the world? Or save it? How many of these bugs are real? And how many of them are real but other pieces of software have worked around those bugs making the whole system work?

And what will be the blow-back of fixing them…

 

And while you sit there with the svn commit about to change the structure of the code of the ancients, you wonder if your hubris is about to bite you in the ass… How could code that has worked for so long, be broken?

And your management team looks at you like those tribal leaders who looked at the explorers, with suspicion and doubt and fear. And you can hear them telling the village youth to arm themselves and kill the interloper before he causes too much harm… Or are they like the hot woman or man begging the evil villain to not destroy the world, or asking the hero:

Are you sure this is going to work?

No fear, the ancients were humans, just like you, you tell them… And that bag of sand is about the same weight as the idol…

Run Indy! Run!

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: innovation

The iPhone did change everything revisiting my predictions from 7 years ago.

September 12, 2014 by kostadis roussos Leave a Comment

7 years ago, I wrote a post questioning the Apple Fan Boys statements that the iPhone changed everything.

I got somethings very right. And I, obviously, got some things very wrong.

My assumption that unlike the iPod Apple would not rule the cellphone market turned out to be correct. My other assumption the iPhone would push the design of phones like the original Mac did turned out to be right.

My original assumption that MS and the cellphone vendors would create a viable alternative ecosystem that would own a much broader chunk than Apple turned out to be partially correct. Instead of MS, the real winner was Google who released the Android.

 

Let’s look at what I said and got right and wrong.

  1. The iPhone was crucial to Apple. And yes it was.
  2. The iPhone was going to push technology trends. Oh boy did it ever
  3. That it was going to be a marginal player. Oh boy was I wrong! WRONG. The share of profits is staggering.
  4. That integration with laptops was important. WRONG! WRONG! WRONG! Obviously I had no idea how much more important integration with cloud services was going to be.
  5. That Microsoft was going to be the bigger threat. OOOPS! Google wasn’t even mentioned! Of course, I wrote the post before Android shipped so that’s my defense. I could not imagine that it would take MS so frigging long to build a credible OS for the phone. And I suspect that Nadella will end that experiment soon.
  6. That the mobile phone providers were going to compete and push Apple into a niche. Right but I guessed wrong on who would do that. Samsung did. Nokia made the strategically boneheaded to go with Windows Mobile instead of Android. A bunch of other players did some good stuff.
  7. The laptop market that I thought was important turns out to be less important than I ever could have imagined for Apple.
  8. And of course, I completely misunderstood the app economy.

7 years later many it’s fun to point out how wrong everyone else got it – it’s even more fun to see how wrong YOU got it 😉

Share this:

  • Email a link to a friend (Opens in new window) Email
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X
  • Share on Tumblr (Opens in new window) Tumblr
  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on WhatsApp (Opens in new window) WhatsApp

Like this:

Like Loading…

Filed Under: innovation, Jobs

  • « Previous Page
  • 1
  • …
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • Next Page »

Loading Comments...

    %d