Splitting Light: Season 1 - Episode 34


Splitting light

Season 1 Episode 34

Importance of upstreaming

If you are no longer interested in the newsletter, please unsubscribe

Once the second generation network device was working, the work to backport the new code library back to every other device began. That meant updating the codebase everywhere. This wasn’t too hard as the code was unified, only the configuration changed dynamically by looking at hardware flags or through communication with it using built-in protocols.

Having to port forward the patches we had done had taken a lot of time. The organization of the code had been changed by the vendor. To enact the same change had required reading a lot of code and took too much time to our liking. To prevent that from happening again, I sent all the modifications we had done to our support engineer. This was done so that the fixes would be maintained by the vendor and not us. Deporting the responsibility of the maintenance and, as well, making the codebase better for everyone. It depended on how you looked at it.

The next step was making sure that we could easily update the library when we needed to. That was done using several scripts and some command line magic. It wasn’t elegant or pretty but it worked enough for our needs. From that point on, it was simpler to update the version.

My approach on this came partly from my very small experience in the open source world. When I had done a bit of packaging, whatever patch required to make the software work would be included initially. Then the goal was to upstream those changes as much as possible. As the local patches were included, you removed them. Getting as close as possible to the vanilla software. It made it easier for the maintainers, which, by the way, is a very hard job to do. Especially freely, on your own time. In the end, it boils down to time. Most open source software has limited time. Even corporate open source like Linux or Firefox are not keen on wasting time.

It’s contributing back to better tech. Whether open source or not, I want better tech. More stable, more usable, more scalable. That is my goal. Everyone has a choice within their context. The choice you make, for me at least, is a reflection of your true self. You choose to keep what you have fixed for you, good for you, but it will reflect in a certain way. Be comfortable with that. Evidently there are limits with sharing and I will go deeper on that train of thoughts in a later episode.

I felt good at the time. It was time to grow more personally. To pivot some focus away from the professional part to the personal one.

(1) Many of the pictures for next episodes come from this wonderful thread about DC5 : https://lafibre.info/opcore/dc5/

If you have missed it, you can read the previous episode here

To pair with :

  • Maggot Brain - Funkadelic
  • One Day in the Life of Ivan Denisovich by Aleksandr Solzhenitsyn


Vincent Auclair

Connect with me on your favorite network!

Oud metha, Dubai, Dubai 00000
Unsubscribe · Preferences

Symbol Sled

Business, tech, and life by a nerd. New every Tuesday: Splitting Light: The Prism of Growth and Discovery.

Read more from Symbol Sled

Splitting light Season 1 Episode 33 First power up to network up If you are no longer interested in the newsletter, please unsubscribe At that point we had three generations of compute, one generation of storage and one generation of network. The third generation compute, on my side, wasn’t much work. The screen code was quickly finalized and small bits of code were written to make the communication. The rest was mostly adding special case code paths and adding configuration to make the...

Splitting light Season 1 Episode 32 Excel sheets to configure If you are no longer interested in the newsletter, please unsubscribe Assignment of fixed amount of TCAM memory to subsystems One of the specificities I thought the lab lab’s team had was that we didn’t try to be too smart. We used simple battle tested tools and common systems. The complexity was not in the tools we used but in hiding the complexity in the final output as much as we could. We used excel for multiple things. We used...

Splitting light Season 1 Episode 31 Piercing the abstraction layers If you are no longer interested in the newsletter, please unsubscribe We build abstraction layers in software. We build them to hide the underlying complexity or limits. Operating systems are done to hide the complexity of interfacing with different devices. A SaaS hides the complexity of running and enhancing the software in exchange for a fee. From that you can derive multiple other advantages. On one side, the layers make...