nine things tagged “linux”

On the Tragedy of systemd

Spent a decent portion of my professional life with init.d. Had to deploy a set of Ubuntu servers last week (use FreeBSD at home), which marked my first actual brush with systemd after a long while of sysadmin-ing Linux systems. It’s weird, takes some getting used to, and has a lovely Enterprise™ smell to it1, but I don’t think I mind it too much, especially with a nice cheatsheet. Just ergonomics; no comments on its security and stewardship 🤐

I wanted to know more about it’s history and enjoyed this really excellent talk by Benno Rice. Had no idea that its creator received death threats and various other forms of online abuse over an innocuous set of ideas and piece of software. Unbelievable.

Some select quotes from the talk and about systemd:

People have a complicated relationship with change. I like to say that nerds especially have a really complicated relationship with change. We love it to pieces. Change is awesome when we’re the ones doing it.

Benno Rice

The moral isn’t “Don’t use systemd”, the moral is “Write stuff in better languages than C”. rsyslog doesn’t exactly have an enviable security record either.

@mjg59

and finally,

The moral is “Don’t use systemd. And don’t chain core system functionality to software from teams with a track record of imcompetence.” It’s about better, experienced programmers. Not “better” languages.

@hyc_symas

Word.

  1. I imagine that init.d did too when it was introduced. ↩︎

Linux and Switching

The problem isn’t CPU power. The CPU on any modern PC is going to blow away the processing power of any sort of network switch you’d care to buy except the really high-end ones. (Really high end. So high end that unless you already know them by name you are not going to want to buy them)

Offloading to the GPU would make things worse, not better.

The problem is latency. It takes time for the PC to take the buffer from the NIC, copy it to the to the main memory, process it on the CPU, copy it back down into a buffer, and then push it out to the network. All this copying around takes time. You could have a 30000 GHZ processor and it’s not going to help you out any.

No amount of programming or GPU offloading is going to make your I/O faster or have less latency. This needs to be done in the hardware. PCs are not designed to handle this. They are designed to have huge cache’s were you take a huge amount of data and process it through loops. This is exactly the sort of thing you do NOT want on a switch.

With a switch you want small buffers. You want small buffers optimized to the speed of the networks they are connected to and have the ability to shuffle information from one port to another. You want to get the information in and out as quickly as possible.

That being said I have no doubt that a Linux switch based on commodity hardware would have no problem keeping up with a 1Gb/s or even 10Gb/s network and having performance similar to any typical corporate switch.

The problem then is one of cost, energy, and space. A network switch takes up almost no room on a rack. It uses little electricity and creates little heat compared to a PC-style corporate Linux server. It has lots and lots of ports.

To create a Linux commodity-based switch with 20 or 40 ports the thing is going to be huge, expensive, and hot.

So yes while it can be done it’s not practical.

On using a Linux box as a switch.