To have xperf we need to install the Windows Performance Toolkit (WPT), which contains Xperf.exe. The WPT is distributed as part of the Windows Assessment and Deployment Kit (ADK) or sometimes separately. And can be found here: https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install

After the installation, you can then run the benchmarks as administrator.

1private void foo(...){
2 assert ... //validation is here
3 //rest of the logic
4}

That’s weird, we’re “asserting” the condition. Right? Wrong!

Until that point, I’ve never seen “assert” used in any of the projects I worked on, so I had to do some digging to understand why the validation was not executing.

What is “assert”?

The Oracle documentation defines it as :

 a statement in the Java programming language that enables you to test your assumptions about your program. For example, if you write a method that calculates the speed of a particle, you might assert that the calculated speed is less than the speed of light. … Experience has shown that writing assertions while programming is one of the quickest and most effective ways to detect and correct bugs. As an added benefit, assertions serve to document the inner workings of your program, enhancing maintainability.

Example usage :

1private void setMaxRetries(int maxRetries){
2assert maxRetries>MIN_RETRIES && maxRetries< MAX_RETRIES
3... //perform action
4}

When to use it, when not to use it ?

Ok, reading that and seeing the example made me wonder why it’s so rare to see it used. When do I need to use it? And the persistent question, why is it not executing? Well, reading the docs actually provides all the answers.

As for when to use assertions, the short answer is: probably never. But the intended use is:

• Internal Invariants: To check conditions. If false, indicate a bug in your code. For instance, ensuring a private helper method always receives non-null arguments from within your class.
• Post-conditions: To verify that the state of an object is as expected after a method execution.
• Pre-conditions (for private methods): Similar to internal invariants; checking conditions for private methods that are only called internally.
• Control-flow invariants: For example, in a switch statement with an enum, using assert false in the default case ensures all enum values are handled.

And for when to not use them :

• Validating public method arguments: Public API inputs should be validated using explicit checks (e.g., if (arg == null) throw new IllegalArgumentException();). These validations are crucial for the correct and safe execution of your application and must always be active. assert is designed to be disabled in production.
• Enforcing business rules: Business logic validations (e.g., “An order must have at least one item”) are not programming errors; they are expected conditions that the application must handle gracefully, typically by throwing specific business exceptions or returning error codes.
• Side effects: Assertion conditions should not cause any side effects because they might be disabled. For instance, assert calculateAndSetState(); is a very bad idea.
• Replacing error handling: Assertions are for internal development-time checks, not for handling recoverable runtime errors.

So what was happening ?

Reading through the documentation, I came across the following statements:

There are also situations where you should not use them:

• Do not use assertions for argument checking in public methods. Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled...
• Do not use assertions to do any work that your application requires for correct operation. Because assertions may be disabled…

And that was the answer: assertions can be disabled and, indeed, they are by default. When you run a Java application from the command line, assertions are not active unless explicitly enabled. This is a deliberate design choice, reflecting their role as development-time debugging aids rather than production-time safeguards. To enable assertions, you can run the application passing the flags --enableassertions or -ea.

The Fix:

The fix was very simple. Once I understood what was happening, it was just a matter of replacing the assertion with an if statement that throws a descriptive exception.

Conclusion:

This bug highlighted a crucial distinction: assert is a tool for catching internal programming errors during development and testing, but it is not a substitute for runtime validation and error handling of external inputs or business logic.

The silent failure of the assert in our production environment reinforced a fundamental best practice: never rely on assertions for code that must execute for your application to be correct and secure. If a condition is critical for the application’s functionality or data integrity, it must be validated with explicit if statements and appropriate exception handling, ensuring it runs reliably regardless of JVM flags.

references and further reading:

• Oracle documentation
• This stackoverflow answer
• Another stackoverflow discussion

This cryptic message, often followed by Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.48/containers/json": dial unix /var/run/docker.sock: connect: permission denied, indicates that your user doesn’t have the necessary permissions to communicate with the Docker daemon. This leaves you in a bind, unable to use Docker without sudo for every command—which isn’t ideal for workflow or security.

You try to add your user to the “docker” group so you can run docker without sudo. And surprise again, the “docker” group is not created. You create the docker group, add your user to it, and still permission error.

Why did this happen, especially with the Ubuntu installer’s Docker checkbox?

The Ubuntu server installer installs Docker as a Snap package. Snaps are designed for confinement and isolation, meaning they run in a more restricted environment for security. Unlike traditional apt package installations, the Docker Snap does not automatically handle the creation of the docker group or add your user to it due to this confinement model. This leaves you without direct access to the Docker socket, forcing you to use sudo.

Checking and Correcting Docker Socket Permissions

To check if the docker group is created run:

getent group | grep docker

If the result is empty then create the group by running :

sudo groupadd docker

and add your user:

sudo usermod -a -G docker {username}

If your group membership is confirmed, let’s look at the actual permissions of the Docker socket file:

ls -l /var/run/docker.sock

You should typically see something like this:

srw-rw---- 1 root docker 0 Jul  X HH:MM /var/run/docker.sock

Key things to look for:

• Ownership: root should be the owner.
• Group: docker should be the group.
• Permissions: srw-rw---- means:
  • s: It’s a socket file.
  • rw-: Read and write for the owner (root).
  • rw-: Read and write for the group (docker).
  • ---: No permissions for others.

If the group is not docker or the permissions are different (e.g., rw-r-----), it might be misconfigured.

If the permissions are wrong, you can fix them:

sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock

Important Note: Some guides suggest sudo chmod 666 /var/run/docker.sock. While this will fix the permission error, it’s a security risk as it gives everyone read/write access to the Docker socket, which is equivalent to giving them root access to your system. Avoid chmod 666 for the Docker socket.

Important Considerations:

• Reliability: While possible, USB Ethernet adapters can sometimes be less reliable than integrated or PCIe Ethernet cards. For critical production environments, a PCIe card is generally recommended if available.
• Driver Support: Most modern USB Ethernet adapters use common chipsets (like Realtek) that are usually supported by the Linux kernel (which Proxmox is based on). However, if you have an obscure adapter, you might need to install additional drivers.
• Interface Naming: Linux (and thus Proxmox) uses consistent network interface naming (e.g., enx followed by part of the MAC address, or ethX). Be aware that if you plug the USB adapter into a different USB port, its name might change, which can break your configuration. You can use persistent naming if this becomes an issue (see the Proxmox Network Configuration documentation for systemd-networkd link files).

Steps to Configure Ethernet over USB in Proxmox:

We’ll primarily be working with the /etc/network/interfaces file, which is where Proxmox manages its network configuration.

1. Connect the USB Ethernet Adapter:

• Plug your USB Ethernet adapter into an available USB port on your Proxmox server.
• Connect an Ethernet cable from the adapter to your network.

2. Identify the USB Ethernet Interface:

• Access your Proxmox server’s shell (via SSH or direct console access).
• Run the following command to list all network interfaces:

1ip a

or

1ifconfig -a

• Look for a new interface that wasn’t there before. It will likely start with enx followed by a long hexadecimal string (e.g., enx0123456789ab) or potentially usb0 if it’s a very simple adapter or a USB tethered device. Note down this interface name.

3. Edit the Network Configuration File:

• Open the /etc/network/interfaces file using a text editor like nano:

1nano /etc/network/interfaces

4. Add a New Network Bridge for the USB Adapter:

Proxmox uses Linux bridges (vmbrX) to manage network interfaces and allow VMs/containers to access the physical network. You’ll create a new bridge and assign your USB Ethernet interface to it.

• Option A: DHCP Configuration (if your network has a DHCP server)
• Add the following lines to the end of the file, replacing enx0123456789ab with the actual name of your USB Ethernet interface:

1auto vmbr1
2iface vmbr1 inet dhcp
3bridge-ports enx0123456789ab
4bridge-stp off
5bridge-fd 0

• Option B: Static IP Configuration

Add the following lines, replacing enx0123456789ab with your USB Ethernet interface name, 192.168.1.10/24 with your desired IP address and subnet mask, and 192.168.1.1 with your gateway:

1   auto vmbr1
2   iface vmbr1 inet static       
3		address 192.168.1.10/24
4		gateway 192.168.1.1
5		bridge-ports enx0123456789ab
6		bridge-stp off
7		bridge-fd 0

• Note: Only one bridge on your Proxmox host can have a gateway defined. If you already have a vmbr0 with a gateway, do not add a gateway to vmbr1. If vmbr1 is your only network connection or your primary one, then it should have the gateway.

• Explanation of the bridge parameters:

• auto vmbr1: Tells Proxmox to bring up this bridge automatically on boot.

• iface vmbr1 inet dhcp (or inet static): Configures the bridge to get an IP address via DHCP or to use a static IP.

• bridge-ports enx0123456789ab: Specifies that the physical USB Ethernet interface will be a member of this bridge.

• bridge-stp off: Disables Spanning Tree Protocol on the bridge (generally recommended for simple home lab setups).

• bridge-fd 0: Sets the bridge forward delay to 0 seconds (reduces the time it takes for the bridge to start forwarding traffic).

5. Save and Apply Changes:

• Save the interfaces file (Ctrl+O, then Enter, then Ctrl+X in nano).

• Apply the network configuration changes.

• Recommended (Proxmox VE 7.0+ with ifupdown2):

 systemctl restart networking

Then, you can verify the status:

systemctl status networking

And apply changes in the Proxmox GUI by clicking “Apply Configuration” in the Network section of your node.

• If systemctl restart networking doesn’t work or you’re on an older Proxmox version, or for more critical changes (requires a brief network outage):

reboot

6. Verify Network Connectivity:

• After applying changes or rebooting, check if your Proxmox host has network connectivity through the new USB Ethernet adapter.

ip a

Verify that vmbr1 (or whatever bridge name you used) has an IP address.

ping google.com

or ping an IP address on your local network.