Customize chat responses in VS Code for GitHub Copilot

You can define custom instructions in two ways:

  1. Using a .github/copilot-instructions.md file in your workspace
  2. Directly in your VS Code settings through settings.json

If you define custom instructions in both the .github/copilot-instructions.md file and in settings, Copilot tries to combine instructions from both sources.

Custom instructions for code generation are not used for code completions and are only used in chat.

Custom instructions example

# Project coding standards

## TypeScript Guidelines
- Use TypeScript for all new code
- Follow functional programming principles where possible
- Use interfaces for data structures and type definitions
- Prefer immutable data (const, readonly)
- Use optional chaining (?.) and nullish coalescing (??) operators

## React Guidelines
- Use functional components with hooks
- Follow the React hooks rules (no conditional hooks)
- Use React.FC type for components with children
- Keep components small and focused
- Use CSS modules for component styling

## Naming Conventions
- Use PascalCase for component names, interfaces, and type aliases
- Use camelCase for variables, functions, and methods
- Prefix private class members with underscore (_)
- Use ALL_CAPS for constants

## Error Handling
- Use try/catch blocks for async operations
- Implement proper error boundaries in React components
- Always log errors with contextual information

Use a .github/copilot-instructions.md file

You can store custom instructions in your workspace or repository in a .github/copilot-instructions.md file and describe your coding practices, preferred technologies, and project requirements by using Markdown.

VS Code automatically includes the instructions from the .github/copilot-instructions.md file to every chat request and applies them for generating code.

To use a .github/copilot-instructions.md file:

  1. Set the github.copilot.chat.codeGeneration.useInstructionFiles setting to true to instruct Copilot in VS Code to use the custom instructions file.
  2. Create a .github/copilot-instructions.md file at the root of your workspace. If needed, create a .github directory first.
  3. Add natural language instructions to the file. You can use the Markdown format.

    Whitespace between instructions is ignored, so the instructions can be written as a single paragraph, each on a new line, or separated by blank lines for legibility.

NoteGitHub Copilot in Visual Studio also detects the .github/copilot-instructions.md file. If you have a workspace that you use in both VS Code and Visual Studio, you can use the same file to define custom instructions for both editors.

Use settings

You can also configure custom code-generation instructions in your user or workspace settings. The following table lists the settings for each type of custom instruction.

Type of instruction Setting name
Code generation github.copilot.chat.codeGeneration.instructions
Test generation github.copilot.chat.testGeneration.instructions
Code review github.copilot.chat.reviewSelection.instructions
Commit message generation github.copilot.chat.commitMessageGeneration.instructions
Pull request title and description generation github.copilot.chat.pullRequestDescriptionGeneration.instructions

You can define the custom instructions as text in the settings value or reference an external file in your workspace.

The following code snippet shows how to define a set of instructions in the settings.json file. To define instruction directly in settings, configure the text property. To reference an external file, configure the file property.

"github.copilot.chat.codeGeneration.instructions": [
  {
    "text": "Always add a comment: 'Generated by Copilot'."
  },
  {
    "text": "In TypeScript always use underscore for private field names."
  },
  {
    "file": "general.instructions.md" // import instructions from file `general.instructions.md`
  },
  {
    "file": "db.instructions.md" // import instructions from file `db.instructions.md`
  }
],

Tips for defining custom instructions

  • Keep your instructions short and self-contained. Each instruction should be a single, simple statement. If you need to provide multiple pieces of information, use multiple instructions.
  • Don’t refer to external resources in the instructions, such as specific coding standards.
  • Make it easy to share custom instructions with your team or across projects by storing your instructions in an external file. You can also version control the file to track changes over time.
  • Split instructions into multiple files and add multiple file references to your settings. This approach is useful for organizing instructions by topic or type of task.

References
https://code.visualstudio.com/docs/copilot/copilot-customization

Dual Boot Clock Issues

If you’re using dual-boot Windows alongside a Linux distribution (like Fedora, Ubuntu, etc.), you’ve probably encountered that frustrating issue where the clock shows the wrong time after switching from one OS to the other. It drove me crazy! This post is a quick reminder for my future self (and maybe you!) on why this happens and the best way I found to fix it permanently.

The Root Cause: A Tale of Two Time Standards

The heart of the problem lies in how Windows and Linux, by default, interpret the time stored in your computer’s Hardware Clock (also known as the RTC or CMOS clock). This is the clock that keeps running even when your PC is off, thanks to that little battery on the motherboard.

  • Windows: Assumes the time stored in the Hardware Clock is Local Time – the actual time on the clock in your specific time zone (e.g., Eastern Daylight Time, Pacific Standard Time), including adjustments for Daylight Saving Time (DST).
  • Linux (most distros): Assumes the time stored in the Hardware Clock is Coordinated Universal Time (UTC) – the global time standard that doesn’t change with time zones or DST. Linux then calculates your correct local time based on UTC plus your selected time zone settings.

When you switch operating systems, they read the Hardware Clock based on their own assumption. One OS might then “correct” the Hardware Clock according to its standard, making it wrong for the other OS when you boot into it next. This back-and-forth causes the time drift.

The Fix: Tell Windows the Hardware Clock is UTC

The most robust solution is to make Windows adopt the same standard as Linux: interpreting the Hardware Clock as UTC. This requires a simple change in the Windows Registry.

Why this method is generally preferred:

  • It aligns both operating systems with a universal standard (UTC).
  • UTC doesn’t have ambiguities related to Daylight Saving Time transitions, making it more reliable for the base hardware clock time.

Here are the steps:

  1. Boot into Windows.
  2. Open Registry Editor: Press Win + R, type regedit, and hit Enter. You’ll likely need to approve the User Account Control (UAC) prompt by clicking “Yes”.
    • Standard Warning: Be careful when editing the registry. Incorrect changes can cause system instability. Stick precisely to these instructions.
  3. Navigate to the Key: In the left-hand pane of the Registry Editor, navigate to this specific location: 
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

    (Expand HKEY_LOCAL_MACHINE, then SYSTEM, CurrentControlSet, Control, and finally click on TimeZoneInformation).

  4. Create the DWORD Value:
    • In the right-hand pane (showing the values within TimeZoneInformation), right-click on an empty space.
    • Select New -> DWORD (32-bit) Value.
    • Crucial: Even if you are using 64-bit Windows, you must select DWORD (32-bit) Value.
    • Name this new value exactly: 
      RealTimeIsUniversal
  5. Set the Value Data:
    • Double-click the RealTimeIsUniversal value you just created.
    • In the “Value data” box, type 1.
    • Ensure the “Base” is set to Hexadecimal (though it makes no difference for the value 1).
    • Click OK.
  6. Close Registry Editor.
  7. Reboot Your Computer: The change takes effect after a restart.

Use a Self-Signed SSL Certificate for Nginx Server

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

Modify Your Nginx Server Block:

server {
    listen 443 ssl;
    server_name your_domain.com;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

    location / {
        # Your proxy or root configurations
    }
}

sudo nginx -t
sudo systemctl reload nginx

 

Set Battery Charge Limit in Fedora

sudo nano /etc/systemd/system/battery-charge-threshold.service

[Unit]
Description=Set battery charge threshold to 60%
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo 60 > /sys/class/power_supply/BAT0/charge_control_end_threshold'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now battery-charge-threshold.service

 

Disable systemd-networkd-wait-online.service in Ubuntu Server

In Ubuntu Server, the systemd-networkd-wait-online.service is responsible for waiting until the network is fully online before allowing the boot process to continue. This service can sometimes cause delays during the boot process if the network configuration takes a long time to initialize.

1. Disable the Service

To completely disable the systemd-networkd-wait-online.service, run the following command:

sudo systemctl disable systemd-networkd-wait-online.service

This will prevent the service from starting at boot time.

2. Mask the Service (Optional)

If you want to ensure that the service cannot be started manually or automatically by any other service, you can mask it:

sudo systemctl mask systemd-networkd-wait-online.service

Masking creates a symbolic link to /dev/null, making it impossible for the service to start unless explicitly unmasked.

Use an X.509 Certificate to encrypt the data protection keys in ASP.NET Blazor

In your Blazor application, modify the Program.cs file to configure data protection with certificate-based encryption.

using Microsoft.AspNetCore.DataProtection;
using System.Security.Cryptography.X509Certificates;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();

// Configure Data Protection to use a certificate for key encryption
var certificate = X509CertificateLoader.LoadPkcs12FromFile("path_to_certificate.pfx", "password");
builder.Services.AddDataProtection()
    .ProtectKeysWithCertificate(certificate)
    .PersistKeysToFileSystem(new DirectoryInfo(keyFolderPath))
    .SetApplicationName("ERP");

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.MapBlazorHub();
app.MapFallbackToPage("/_Host");

app.Run();

 

Install Syncthing on Ubuntu 24.04

# Add the release PGP keys:
sudo mkdir -p /etc/apt/keyrings
sudo curl -L -o /etc/apt/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg
# Add the "stable" channel to your APT sources:
echo "deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable" | sudo tee /etc/apt/sources.list.d/syncthing.list
# Update and install syncthing:
sudo apt-get update
sudo apt-get install syncthing

Syncthing can be run as a service so that it starts automatically on boot.

  1. Enable the Syncthing service : By default, Syncthing installs a systemd service for the user syncthing. You can enable it to start on boot. 
    sudo systemctl enable syncthing@<username>.service

    Replace <username> with the username of the user who will run Syncthing. For example, if your username is ubuntu, the command would be:

    sudo systemctl enable syncthing@ubuntu.service
  2. Start the Syncthing service : Once enabled, start the Syncthing service. 
    sudo systemctl start syncthing@<username>.service

By default, Syncthing runs on localhost and listens on port 8384.

References
https://apt.syncthing.net/