Technology Linux
•

Getting an openSUSE machine online

This week I’ve been cloning machines, but each new machine has slightly different hardware, even if it’s just a MAC address or serial number.

So, a quick disclaimer I’m using openSUSE 11.3 and so things will be slightly different for different versions of SUSE or different distros.

Get online

SUSE unlike some of the more user friendly OS’s doesn’t go out of it’s way to get you online. So we need to manually tell it what to do. First open a terminal and log in as a system admin:

1

su

Now view the network connections:

1

ifconfig -a

This should tell you what you’ve got, what’s connected and what’s trying to connect. Now remember the MAC address of the port you want to connect and open up YAST from the start menu (under Computer)

Open up Network Settings.

Delete the old connections, and set up the new ones. Generally, for most instances you’ll just want to Edit the new connection and set it to acquire it’s IP using DHCP, but if you’re using a corporate network then you may need to give it a default gateway address as well.

Click Next, and Finish in YAST and allow it to write the new settings. Hopefully your network should now be up and running.

Tidy up ports (ie changing ethX to ethY)

For some of my software it uses licenses based upon the MAC address of eth0, and obviously with nothing on eth0 it falls over a bit. For this reason I needed to change by eth2 to eth0.

So in a terminal as a super user

1
2

rcnetwork stop
cd /etc/udev/rules.d

This bit is definitely different on different versions of SUSE, so list your directory and change as appropiate. And if you dont use nano, use vi or kate

1

nano 70-persistent-net.rules

At the bottom of this file is a line starting with SUBSYSTEM and at the end of the line is something like

1

NAME = “ethX”

Simply change the X to whichever number you like, but remember you’ll probably have to change the Network Settings in YAST again after this

1

rcnetwork start

Restart your PC, and then check with ifconfig if needs be.

Older post

PyMOL with Ubuntu 11.10 rendering problems

Newer post

Clone an (openSUSE) machine and make it functional

Further reading for leaders

Explore the archive

Blog Technology Website Wordpress Hugo
•

Dumpster diving & retrieval of Wordpress content

Backing things up

Linux Pymol
•

PyMOL visualising e2 rotamers

This morning whilst writing some reports I wanted to show some rotamer populations of my spin label attached to the protein. Whilst MMM provides visualisation, and having had discussions with Jeschke I understand just how difficult it is to do, I do …

Technology Epr Bruker
•

Xepr license work around

Danger

Disclaimer: the author does not condone piracy but this may be used as a temporary measure

​As readers of my work-sided blog posts will be aware, I’ve had some recent problems with …

LEADERSHIP, SCALE, AND THE HUMAN ELEMENT

Principles & Perspectives

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.