Docker makes this dramatically simpler. You describe what you want with environment variables, run docker compose up -d, and it is done. No config files to hand-edit, no leftover state from previous experiments, easy to tear down and rebuild.

This article walks through a complete setup using two containers: samba for the file sharing itself, and wsdd2 so the server appears automatically in the Windows network neighborhood.

What You Need

• A Linux host with Docker and Docker Compose installed
• The directories you want to share already existing on the host
• Ports 445 (SMB) and 1900 (WS-Discovery) not blocked by a firewall

The Compose File

name: samba

services:
    samba:
        image: ghcr.io/antrv/samba
        container_name: samba
        restart: unless-stopped
        cap_add:
            - NET_ADMIN
        network_mode: host
        volumes:
            - /etc/localtime:/etc/localtime:ro
            - /host/share1:/shares/share1
            - /host/share2:/shares/share2
        environment:
            - MACHINENAME=FILES
            - MACHINETITLE=File Server
            - WORKGROUP=HOME

            - USER1_NAME=username
            - USER1_UID=1000
            - USER1_PASSWORD=password
            #- USER1_PASSWORD_FILE=/run/secrets/user1_password

            - SHARE1_NAME=share1
            - SHARE1_PATH=/shares/share1
            - SHARE1_COMMENT=Share 1
            - SHARE1_WRITE_LIST=@users
            - SHARE1_BROWSEABLE=yes
            - SHARE1_READ_ONLY=yes

            - SHARE2_NAME=share2
            - SHARE2_PATH=/shares/share2
            - SHARE2_COMMENT=Share 2
            - SHARE2_WRITE_LIST=@users
            - SHARE2_BROWSEABLE=yes
            - SHARE2_READ_ONLY=yes

    wsdd2:
        image: ghcr.io/antrv/wsdd2
        container_name: wsdd2
        restart: unless-stopped
        network_mode: host
        environment:
            - MACHINENAME=FILES
            - WORKGROUP=HOME

Save this as docker-compose.yaml, adjust the values for your environment, and bring it up:

docker compose up -d

Walking Through the Configuration

Host networking

Both containers use network_mode: host. This is not optional for Samba. SMB relies on NetBIOS name resolution and multicast discovery protocols that do not work correctly through Docker's default NAT bridge. With host networking the container shares the host's network stack directly, so Windows clients see it as a regular machine on the LAN.

The samba container

Server identity

MACHINENAME=FILES        # NetBIOS name — how Windows sees the machine
MACHINETITLE=File Server # Description shown in network browser
WORKGROUP=HOME           # Must match your Windows workgroup

Set MACHINENAME to whatever you want the server to appear as in \\FILES\share1 style paths. Keep it short, no spaces.

Users

USER1_NAME=username
USER1_UID=1000
USER1_PASSWORD=password

The container creates a Linux user with this UID and registers it with Samba's own password database. The UID matters when the share directory on the host is owned by a specific user — matching UIDs avoids permission problems without chmod 777 hacks.

You can add as many users as you need by incrementing the number: USER2_NAME, USER2_PASSWORD, and so on.

Keeping passwords out of the compose file

Putting passwords in environment variables is convenient but means they appear in docker inspect output and in your compose file committed to git. The image supports a file-based alternative:

# USER1_PASSWORD_FILE=/run/secrets/user1_password

With Docker secrets or a bind-mounted file, the container reads the password from the file instead. For a home server the inline password is fine; for anything more sensitive, use the file approach.

Shares

SHARE1_NAME=share1          # Share name — appears as \\FILES\share1
SHARE1_PATH=/shares/share1  # Path inside the container
SHARE1_COMMENT=Share 1      # Description shown to clients
SHARE1_BROWSEABLE=yes       # Visible when browsing the network
SHARE1_READ_ONLY=yes        # yes = read-only for everyone by default
SHARE1_WRITE_LIST=@users    # Who gets write access

SHARE1_READ_ONLY=yes combined with SHARE1_WRITE_LIST=@users means the share is read-only by default but any user in the users group can write. This is a safe default — only authenticated users can make changes. To make a share fully read-only for everyone, set WRITE_LIST to an empty value or omit it.

Add more shares by incrementing the number: SHARE2_NAME, SHARE2_PATH, and so on up to however many you need.

Volumes

- /etc/localtime:/etc/localtime:ro   # Keep container clock in sync with host
- /host/share1:/shares/share1        # Mount host directory into the container

Replace /host/share1 with the actual path on your Linux host. The right side (/shares/share1) is what you set in SHARE{N}_PATH.

The wsdd2 container

WS-Discovery is the protocol Windows 10 and later uses to find machines in the network neighborhood. Without it, your Samba server works fine — Windows clients can connect by typing \\FILES directly — but it will not show up automatically when browsing the network.

The wsdd2 container handles this. Give it the same MACHINENAME and WORKGROUP as the samba container and it takes care of the rest.

Connecting from Windows

Once the containers are running, open File Explorer on a Windows machine on the same network. Within a minute or two the server should appear under Network with the name you set in MACHINENAME.

You can also connect directly:

1. Press Win + R
2. Type \\FILES (replace with your MACHINENAME)
3. Press Enter

Windows will prompt for credentials. Enter the username and password you configured with USER1_NAME and USER1_PASSWORD.

To map a share as a persistent drive letter, right-click on the share in File Explorer and choose Map network drive.

Security Notes

The image enforces SMB2 as the minimum protocol version — SMB1 is disabled entirely. SMB1 has known critical vulnerabilities (it is what WannaCry exploited) and has no place on a modern network.

All access is authenticated. There is no guest access. The @users group in WRITE_LIST refers to Samba users you explicitly created — not arbitrary network users.

For a home LAN this setup is reasonable. If the server is accessible from outside your network, put it behind a VPN rather than exposing port 445 directly to the internet.

Adding More Users and Shares

The numbering scheme scales linearly. To add a second user and a third share:

USER2_NAME=anotheruser
USER2_PASSWORD=anotherpassword

SHARE3_NAME=media
SHARE3_PATH=/shares/media
SHARE3_COMMENT=Media Library
SHARE3_READ_ONLY=yes

Restart the container after changing environment variables:

docker compose up -d --force-recreate samba

Conclusion

Two containers, a handful of environment variables, and your Linux server is a fully functional SMB file server that Windows machines find automatically on the network. No config file editing, no system-level user management to undo later, and the whole thing lives in a single compose file you can version-control.

The images are available on GitHub Container Registry:

• ghcr.io/antrv/samba
• ghcr.io/antrv/wsdd2

Source and the example compose file are at github.com/antrv/docker-images.

You might need to know if a specific interface exists in a collection, find the specific index of a type to access a corresponding value in a std::tuple, or strip away redundant duplicates to create a canonical list of types.

In this article, we will implement three crucial set-operations: contains (existence), index_of (lookup), and unique (deduplication).

1. Existence: The contains Check

Checking if a type exists within a pack used to require complex recursive inheritance or std::disjunction. With C++17, this becomes a trivial one-liner using Fold Expressions.

We add a static constexpr boolean to our main structure. This allows users to write Pack::contains<int> effectively.

template <class... Ts>
struct TypePack : std::type_identity<TypePack<Ts...>> {
    // ... previous code ...

    // C++17 Fold Expression to check for type existence
    template <class T>
    static constexpr bool contains = (std::is_same_v<T, Ts> || ...);

    // ...
};

2. Location: The index_of Operation

Knowing a type exists is often only half the battle. If you are building a storage system (like a Variant or a Tuple wrapper), you often need the numerical index of that type to access memory.

Since parameter packs cannot be indexed at runtime, we perform a compile-time linear search. We recurse through the pack:

1. Found: Return 0.

2. Not Found: Return the result of the recursion + 1.

3. End of Pack: Return a sentinel value (max size_t) to indicate failure.

We add this as a static member to TypePack:

template <class... Ts>
struct TypePack : std::type_identity<TypePack<Ts...>> {
    // ...
    template <class T>
    static constexpr size_t index_of = details::TypePackIndexOf<T, TypePack>::value;
};

And the implementation logic:

template <class T, class Pack>
struct TypePackIndexOf;

// Base Case: Pack is empty, type not found. Return MAX_SIZE_T.
template <class T>
struct TypePackIndexOf<T, TypePack<>> : 
    std::integral_constant<size_t, std::numeric_limits<size_t>::max()> {};

// Match Case: The head of the pack matches T. Index is 0.
template <class T, class... Ts>
struct TypePackIndexOf<T, TypePack<T, Ts...>> : 
    std::integral_constant<size_t, 0> {};

// Recursive Step: Head does not match. Check the tail.
template <class T, class TFirst, class... Ts>
struct TypePackIndexOf<T, TypePack<TFirst, Ts...>> :
    std::integral_constant<size_t,
        TypePackIndexOf<T, TypePack<Ts...>>::value == std::numeric_limits<size_t>::max() 
            ? std::numeric_limits<size_t>::max() 
            : TypePackIndexOf<T, TypePack<Ts...>>::value + 1
    > {};

3. Uniqueness: The unique Transformation

When automatically generating types (e.g., deducing return types from a set of functions), you often end up with duplicates. To resolve ambiguity, you need to reduce the pack to a set of unique types.

This implementation relies on the TypePackRemove utility we built in Part 6. The strategy is "Filter and Conserve":

1. Take the first type T.

2. Remove all occurrences of T from the rest of the pack.

3. Recurse on the now-filtered tail.

4. Prepend T back to the result.

This ensures order is preserved while duplicates are eliminated.

// Public Alias
template <IsSpecializationOf<TypePack> Pack>
using type_pack_unique_t = details::TypePackUnique<Pack>::type;

// Implementation
template <class Pack>
struct TypePackUnique;

// Base Case: Empty pack is already unique
template <>
struct TypePackUnique<TypePack<>> : std::type_identity<TypePack<>> {};

// Recursive Step
template <class T, class... Ts>
struct TypePackUnique<TypePack<T, Ts...>> :
    TypePackInsertAtFirstPosition<
        T, 
        // 1. Remove T from the tail (Ts...)
        // 2. Compute Unique on that filtered tail
        typename TypePackUnique<
            typename TypePackRemove<T, TypePack<Ts...>>::type
        >::type
    > {};

Validation

We verify our set operations with a suite of tests covering existence, valid/invalid indices, and duplicate removal.

C++

// 1. Testing Contains
TEST(TypePackTests, Contains)
{
    using Pack = TypePack<int, long, double, char>;
    static_assert(Pack::contains<int>);
    static_assert(Pack::contains<double>);
    static_assert(!Pack::contains<char8_t>); // Not in pack

    // Edge case: Empty pack
    static_assert(!TypePack<>::contains<int>);
}

// 2. Testing IndexOf
TEST(TypePackTests, IndexOf)
{
    using Pack = TypePack<int, long, double, char>;

    static_assert(Pack::index_of<int> == 0);
    static_assert(Pack::index_of<double> == 2);
    static_assert(Pack::index_of<char> == 3);

    // Not found returns MAX
    static_assert(Pack::index_of<char8_t> == std::numeric_limits<size_t>::max());
    static_assert(TypePack<>::index_of<int> == std::numeric_limits<size_t>::max());
}

// 3. Testing Unique
TEST(TypePackTests, Unique)
{
    // Input contains duplicates of int, long, and char
    using Pack = TypePack<int, long, int, char, long, long, char, char8_t>;
    using Expected = TypePack<int, long, char, char8_t>;

    static_assert(std::is_same_v<type_pack_unique_t<Pack>, Expected>);

    // Already unique packs remain unchanged
    static_assert(std::is_same_v<type_pack_unique_t<TypePack<int>>, TypePack<int>>);
    static_assert(std::is_same_v<type_pack_unique_t<TypePack<>>, TypePack<>>);
}

Conclusion

With the addition of contains, index_of, and unique, our TypePack has evolved into a fully functional compile-time container. We can now treat variadic templates not just as a list of arguments, but as a searchable, indexable, and distinct set of types.

You can explore the full source code for the library on GitHub, including the implementation details and the comprehensive test suite.

This concludes our deep dive into the core implementation of TypePack. By combining structural manipulation (Concat, Slice) with introspective logic (Find, Unique), we have built a library capable of handling complex C++ metaprogramming tasks with clean, readable syntax.

In this article, we will implement type_pack_flatten_t, a powerful utility that recursively collapses any level of nesting into a single, linear TypePack.

The Goal: Structural Simplification

The objective is to take a complex, multidimensional type structure and normalize it. For example:

• Input: TypePack<int, TypePack<char, TypePack<long>>, double>

• Output: TypePack<int, char, long, double>

Unlike our previous operations, this utility is implemented as a standalone alias rather than a member of the TypePack struct, allowing it to act as a transformation gateway for any pack specialization.

The Implementation: Recursive Concatenation

The beauty of the flatten operation lies in its simplicity when paired with the TypePackConcat utility we built in Part 4.

// Public API
template <IsSpecializationOf<TypePack> Pack>
using type_pack_flatten_t = details::TypePackFlatten<Pack>::type;

// 1. Base Case: If the element is not a TypePack, wrap it in a TypePack to make it "concat-compatible"
template <class T>
struct TypePackFlatten : std::type_identity<TypePack<T>> {
};

// 2. Recursive Step: If it is a TypePack, flatten its contents and concatenate the results
template <class... Ts>
struct TypePackFlatten<TypePack<Ts...>> : 
    details::TypePackConcat<typename TypePackFlatten<Ts>::type...> {
};

How it works:

1. Uniformity: Every element encountered is turned into a TypePack. A simple int becomes TypePack<int>.

2. Expansion: The specialization for TypePack<Ts...> uses the pack expansion Ts... to pass every internal element into TypePackFlatten recursively.

3. Merge: TypePackConcat takes these results and joins them. Because TypePackConcat is designed to handle multiple packs, it effortlessly merges the flattened "sub-packs" into one.

Validation and Edge Cases

The robustness of this implementation is evident when handling empty packs or deeply nested structures. We use static_assert to verify that the hierarchy is correctly collapsed regardless of depth.

TEST(TypePackTests, Flatten1)
{
    using Pack1 = TypePack<TypePack<int>>;
    static_assert(std::is_same_v<type_pack_flatten_t<Pack1>, TypePack<int>>);

    using Pack2 = TypePack<TypePack<TypePack<int>>>;
    static_assert(std::is_same_v<type_pack_flatten_t<Pack2>, TypePack<int>>);
}

TEST(TypePackTests, Flatten)
{
    // A complex mix of types, empty packs, and deep nesting
    using Pack = TypePack<
        short, 
        TypePack<>, 
        TypePack<TypePack<int, TypePack<TypePack<long>>>, TypePack<double>>, 
        TypePack<char8_t, char32_t>, 
        char
    >;

    using Expected = TypePack<short, int, long, double, char8_t, char32_t, char>;

    static_assert(std::is_same_v<type_pack_flatten_t<Pack>, Expected>);
}

Conclusion

Flattening is the "reset button" for type containers. It allows us to perform complex transformations that might result in nesting, knowing that we can always return to a clean, flat state. By leveraging TypePackConcat, we’ve turned a difficult recursive problem into a concise and elegant template specialization.

In the next part, we will explore Set-like operations: how to check for a type's existence, find its index, and ensure all types in a pack are unique.

In this article, we will implement type-based filtering and transformation using remove_t and replace_t.

Advancing the Interface

We add two more aliases to our TypePack. These allow us to perform "search-and-destroy" or "search-and-replace" operations across the entire collection of types.

template <class... Ts>
struct TypePack : std::type_identity<TypePack<Ts...>> {
    // ... previous definitions ...

    // Remove all occurrences of type T
    template <class T>
    using remove_t = details::TypePackRemove<T, TypePack>::type;

    // Replace all occurrences of T with TReplacement
    template <class T, class TReplacement>
    using replace_t = details::TypePackReplace<T, TReplacement, TypePack>::type;
};

Type-Based Removal

The TypePackRemove utility uses recursive pattern matching to scan the pack. Unlike positional removal, this operation visits every element and decides whether to keep it or discard it.

The Logic:

1. Base Case: Removing from an empty pack results in an empty pack.

2. Match Case: If the head of the pack matches the target type T, we discard it and continue with the rest of the pack.

3. No-Match Case: If the head doesn't match, we keep it (using TypePackInsertAtFirstPosition) and recurse into the tail.

template <class T, class Pack>
struct TypePackRemove;

template <class T>
struct TypePackRemove<T, TypePack<>> : std::type_identity<TypePack<>> {
};

template <class T, class...Ts>
struct TypePackRemove<T, TypePack<T, Ts...>> : TypePackRemove<T, TypePack<Ts...>> {
};

template <class T, class TFirst, class...Ts>
struct TypePackRemove<T, TypePack<TFirst, Ts...>> :
    TypePackInsertAtFirstPosition<TFirst, typename TypePackRemove<T, TypePack<Ts...>>::type> {
};

Universal Replacement

TypePackReplace follows a similar recursive structure but with a twist: instead of discarding a matching type, we swap it for a new one.

The Logic:

• If Head == Target, the new pack starts with Replacement.

• If Head != Target, the new pack starts with the original Head.

• Repeat until the pack is empty.

template <class T, class TReplacement, class Pack>
struct TypePackReplace;

template <class T, class TReplacement>
struct TypePackReplace<T, TReplacement, TypePack<>> : std::type_identity<TypePack<>> {
};

template <class T, class TReplacement, class...Ts>
struct TypePackReplace<T, TReplacement, TypePack<T, Ts...>> :
    TypePackInsertAtFirstPosition<TReplacement, typename TypePackReplace<T, TReplacement, TypePack<Ts...>>::type> {
};

template <class T, class TReplacement, class TFirst, class...Ts>
struct TypePackReplace<T, TReplacement, TypePack<TFirst, Ts...>> :
    TypePackInsertAtFirstPosition<TFirst, typename TypePackReplace<T, TReplacement, TypePack<Ts...>>::type> {
};

Validation with static_assert

Our tests demonstrate that these operations work globally—affecting multiple occurrences of the same type throughout the pack.

TEST(TypePackTests, RemoveType)
{
    using Pack = TypePack<int, long, int, double, int>;

    // Removes ALL 'int' instances
    using Result = Pack::remove_t<int>;
    static_assert(std::is_same_v<Result, TypePack<long, double>>);

    // If the type isn't there, the pack remains unchanged
    static_assert(std::is_same_v<Pack::remove_t<char>, Pack>);
}

TEST(TypePackTests, ReplaceType)
{
    using Pack = TypePack<int, long, int>;

    // Replaces ALL 'int' with 'unsigned'
    using Result = Pack::replace_t<int, unsigned>;
    static_assert(std::is_same_v<Result, TypePack<unsigned, long, unsigned>>);
}

Conclusion

By moving from positional to type-based manipulation, we've given our TypePack the ability to "understand" its contents. These recursive patterns are the engine behind powerful library features, such as filtering out unsupported types or automatically upgrading types in a template-heavy API.

In the next part, we will look at how to handle nested structures by implementing an operation to flatten a pack

In the previous chapters, we focused on building and expanding our TypePack. However, effective type manipulation often requires surgical precision in removing unwanted elements. Whether you're stripping specific traits or trimming a pack to fit a function signature, you need a reliable way to "cut" types out.

In this article, we will implement remove_at_t and the more general remove_range_t.

Streamlining the Interface

By now, you might notice a pattern: our complex operations are built by composing simpler ones. We add two new aliases to TypePack that leverage a unified removal logic.

template <class... Ts>
struct TypePack : std::type_identity<TypePack<Ts...>> {
    // ... previous definitions ...

    // Remove a single type at Index
    template <size_t Index>
    using remove_at_t = details::TypePackRemoveRange<Index, 1, TypePack>::type;

    // Remove a chunk of 'Size' types starting at Index
    template <size_t Index, size_t Size>
    using remove_range_t = details::TypePackRemoveRange<Index, Size, TypePack>::type;
};

The Surgical Logic: TypePackRemoveRange

The logic for removing a range is the conceptual inverse of the "Subpack" operation we wrote in Part 3. To remove a range, we don't keep the middle; we keep the ends.

How it works:

1. Prefix: We take the first Index elements.

2. Suffix: We skip everything from the start up to the end of the unwanted range (Index + Size).

3. Join: We concatenate the prefix and the suffix, effectively "stitching" the pack back together over the hole.

4. We use requires clauses and static_assert to ensure that we never attempt to remove elements outside the pack's boundaries.

template <size_t Index, size_t Size, class Pack>
struct TypePackRemoveRange;

template <size_t Index, size_t Size, class...Ts>
requires (Index > sizeof...(Ts) || Size > sizeof...(Ts) || Index + Size > sizeof...(Ts))
struct TypePackRemoveRange<Index, Size, TypePack<Ts...>> {
    static_assert(Index <= sizeof...(Ts), "Index out of range");
    static_assert(Size <= sizeof...(Ts), "Size out of range");
    static_assert(Index + Size <= sizeof...(Ts), "Index + Size out of range");
};

template <size_t Index, size_t Size, class...Ts>
requires (Index <= sizeof...(Ts) && Size <= sizeof...(Ts) && Index + Size <= sizeof...(Ts))
struct TypePackRemoveRange<Index, Size, TypePack<Ts...>> :
    TypePackConcat<typename TypePackFirstN<Index, TypePack<Ts...>>::type, typename TypePackSkipN<Index + Size, TypePack<Ts...>>::type> {
};

Validation with static_assert

Our tests cover both the removal of individual elements and various range sizes, ensuring the "stitching" logic is perfect.

TEST(TypePackTests, RemoveAt)
{
    using Pack = TypePack<int, long, double, char>;

    // Removing the first element
    static_assert(std::is_same_v<Pack::remove_at_t<0>, TypePack<long, double, char>>);

    // Removing a middle element
    static_assert(std::is_same_v<Pack::remove_at_t<2>, TypePack<int, long, char>>);
}

TEST(TypePackTests, RemoveRange)
{
    using Pack = TypePack<int, long, double, char>;

    // Removing a range of 0 elements leaves the pack unchanged
    static_assert(std::is_same_v<Pack::remove_range_t<1, 0>, Pack>);

    // Removing a range in the middle
    static_assert(std::is_same_v<Pack::remove_range_t<1, 2>, TypePack<int, char>>);

    // Removing everything
    static_assert(std::is_same_v<Pack::remove_range_t<0, 4>, TypePack<>>);
}

Conclusion

We have now completed the structural toolkit for our TypePack. We can create, measure, index, slice, grow, and shrink our type containers. This composition-based approach—where RemoveRange is simply a combination of FirstN, SkipN, and Concat—demonstrates the power of building a clean foundation.

In the next part, we will move beyond indices and ranges to work with types directly: we will learn how to remove all occurrences of a specific type and how to replace one type with another across the entire pack.

Expanding the Interface

We introduce two powerful aliases to the TypePack struct: concat_t for merging and insert_at_t for precise placement.

template <class... Ts>
struct TypePack : std::type_identity<TypePack<Ts...>> {
    // ... previous definitions (size, element_t, etc.) ...

    // Merge this pack with any number of other TypePacks
    template <class... Packs>
    using concat_t = details::TypePackConcat<TypePack, Packs...>::type;

    // Insert a single type T at a specific Index
    template <size_t Index, class T>
    using insert_at_t = details::TypePackInsertAt<T, Index, TypePack>::type; 
};

Merging Packs: The TypePackConcat Logic

To ensure type safety, we use the IsSpecializationOf concept. This prevents the user from accidentally trying to concatenate a TypePack with a std::tuple or other unrelated types.

The Implementation

Concatenation is achieved by recursively expanding the internal packs and folding them into a single TypePack.

template <IsSpecializationOf<TypePack>...Packs>
struct TypePackConcat;

template <>
struct TypePackConcat<> : std::type_identity<TypePack<>> {
};

template <class...Ts>
struct TypePackConcat<TypePack<Ts...>> : std::type_identity<TypePack<Ts...>> {
};

template <class...Ts, class...Ts2, IsSpecializationOf<TypePack>...Packs>
struct TypePackConcat<TypePack<Ts...>, TypePack<Ts2...>, Packs...> :
    TypePackConcat<TypePack<Ts..., Ts2...>, Packs...> {
};

This recursive approach allows us to pass an unlimited number of packs to concat_t, flattening them all into one flat structure.

Precise Insertion: The TypePackInsertAt Logic

Inserting an element at an arbitrary index is a perfect demonstration of the "Slicing" tools we built in Part 3. Instead of writing a complex new recursion, we simply:

1. Slice the pack into two halves (before and after the index).

2. Concatenate the first half, the new type, and the second half.

template <class T, size_t Index, class Pack>
struct TypePackInsertAt;

template <class T, size_t Index, class...Ts>
requires (Index > sizeof...(Ts))
struct TypePackInsertAt<T, Index, TypePack<Ts...>> {
    static_assert(AlwaysFalse<std::integral_constant<size_t, Index>>, "Index out of range");
};

template <class T, size_t Index, class...Ts>
requires (Index <= sizeof...(Ts))
struct TypePackInsertAt<T, Index, TypePack<Ts...>> :
    TypePackConcat<
        typename TypePackFirstN<Index, TypePack<Ts...>>::type, 
        TypePack<T>, 
        typename TypePackSkipN<Index, TypePack<Ts...>>::type> {
};

This "Lego-block" approach to metaprogramming makes the code significantly easier to maintain and reason about.

Validation with static_assert

Our tests verify that concatenation handles empty packs correctly and that insertion works at the boundaries (index 0 and index size).

TEST(TypePackTests, Concat)
{
    using Pack0 = TypePack<>;
    using Pack1 = TypePack<float>;
    using Pack2 = TypePack<unsigned, char8_t>;
    using Pack4 = TypePack<int, long, double, char>;
    static_assert(std::is_same_v<Pack0::concat_t<Pack0>, TypePack<>>);
    static_assert(std::is_same_v<Pack0::concat_t<Pack1>, TypePack<float>>);
    static_assert(std::is_same_v<Pack0::concat_t<Pack2>, TypePack<unsigned, char8_t>>);
    static_assert(std::is_same_v<Pack0::concat_t<Pack4>, TypePack<int, long, double, char>>);
    static_assert(std::is_same_v<Pack1::concat_t<Pack0>, TypePack<float>>);
    static_assert(std::is_same_v<Pack1::concat_t<Pack1>, TypePack<float, float>>);
    static_assert(std::is_same_v<Pack1::concat_t<Pack2>, TypePack<float, unsigned, char8_t>>);
    static_assert(std::is_same_v<Pack1::concat_t<Pack4>, TypePack<float, int, long, double, char>>);
    static_assert(std::is_same_v<Pack2::concat_t<Pack0>, TypePack<unsigned, char8_t>>);
    static_assert(std::is_same_v<Pack2::concat_t<Pack1>, TypePack<unsigned, char8_t, float>>);
    static_assert(std::is_same_v<Pack2::concat_t<Pack2>, TypePack<unsigned, char8_t, unsigned, char8_t>>);
    static_assert(std::is_same_v<Pack2::concat_t<Pack4>, TypePack<unsigned, char8_t, int, long, double, char>>);
    static_assert(std::is_same_v<Pack4::concat_t<Pack0>, TypePack<int, long, double, char>>);
    static_assert(std::is_same_v<Pack4::concat_t<Pack1>, TypePack<int, long, double, char, float>>);
    static_assert(std::is_same_v<Pack4::concat_t<Pack2>, TypePack<int, long, double, char, unsigned, char8_t>>);
    static_assert(std::is_same_v<Pack4::concat_t<Pack4>, TypePack<int, long, double, char, int, long, double, char>>);
}

TEST(TypePackTests, InsertAt)
{
    using Pack = TypePack<int, long, double, char>;
    static_assert(std::is_same_v<Pack::insert_at_t<0, float>, TypePack<float, int, long, double, char>>);
    static_assert(std::is_same_v<Pack::insert_at_t<1, float>, TypePack<int, float, long, double, char>>);
    static_assert(std::is_same_v<Pack::insert_at_t<2, float>, TypePack<int, long, float, double, char>>);
    static_assert(std::is_same_v<Pack::insert_at_t<3, float>, TypePack<int, long, double, float, char>>);
    static_assert(std::is_same_v<Pack::insert_at_t<4, float>, TypePack<int, long, double, char, float>>);
}

Conclusion

With the addition of concatenation and insertion, our TypePack is no longer a static snapshot of types. It is now a dynamic structure that can be merged, extended, and rebuilt at will. We have successfully moved from basic introspection to active structural transformation.

In the next part, we will explore how to shrink our containers: removing specific elements and deleting entire ranges from the pack.

In this article, we will implement first_n_t, skip_n_t, and the versatile subpack_t.

Expanding the TypePack Interface

We add three new alias templates to our core TypePack structure. These act as the public API for our slicing operations.

template <class... Ts>
struct TypePack : std::type_identity<TypePack<Ts...>> {
    static constexpr size_t size = sizeof...(Ts);

    // ... previous definitions ...

    template <size_t Size>
    using first_n_t = details::TypePackFirstN<Size, TypePack>::type;

    template <size_t Size>
    using skip_n_t = details::TypePackSkipN<Size, TypePack>::type;

    template <size_t Index, size_t Size>
    using subpack_t = details::TypePackSubPack<Index, Size, TypePack>::type;
};

The Supporting Machinery

To implement these, we need helper utilities to rebuild packs. The most basic operations are inserting a type at the beginning or the end of an existing TypePack.

1. Internal Helpers: Insertion

template <class T, class Pack>
struct TypePackInsertAtFirstPosition;

template <class T, class... Ts>
struct TypePackInsertAtFirstPosition<T, TypePack<Ts...>> 
    : std::type_identity<TypePack<T, Ts...>> {};

2. Taking the First N Types

To get the first N types, we use recursion. We "take" the head of the pack and prepend it to the result of taking N-1 types from the tail.

template <size_t N, class Pack>
struct TypePackFirstN;

template <size_t N>
requires (N != 0)
struct TypePackFirstN<N, TypePack<>> {
    static_assert(AlwaysFalse<std::integral_constant<size_t, N>>, "N is out of range");
};

template <class...Ts>
struct TypePackFirstN<0, TypePack<Ts...>> : std::type_identity<TypePack<>> {
};

template <size_t N, class T, class...Ts>
requires (N != 0)
struct TypePackFirstN<N, TypePack<T, Ts...>> :
    TypePackInsertAtFirstPosition<T, typename TypePackFirstN<N - 1, TypePack<Ts...>>::type> {
};

3. Skipping N Types

Skipping is simpler than taking. We don't need to rebuild the pack; we simply discard the head until N reaches zero.

template <size_t N, class Pack>
struct TypePackSkipN;

template <size_t N>
requires (N != 0)
struct TypePackSkipN<Size, TypePack<>> {
    static_assert(AlwaysFalse<std::integral_constant<size_t, N>>, "N is out of range");
};

template <class...Ts>
struct TypePackSkipN<0, TypePack<Ts...>> : std::type_identity<TypePack<Ts...>> {
};

template <size_t N, class T, class...Ts>
requires (N != 0)
struct TypePackSkipN<N, TypePack<T, Ts...>> : TypePackSkipN<N - 1, TypePack<Ts...>> {
};

4. The General Subpack (Slice)

The subpack_t operation is a beautiful example of composition. To get a range starting at Index with a specific Size, we first skip the prefix and then take the requested number of elements from the remainder.

template <size_t Index, size_t Size, class Pack>
struct TypePackSubPack;

template <size_t Index, size_t Size, class...Ts>
requires (Index > sizeof...(Ts) || Size > sizeof...(Ts) || Index + Size > sizeof...(Ts))
struct TypePackSubPack<Index, Size, TypePack<Ts...>> {
    static_assert(Index <= sizeof...(Ts), "Index out of range");
    static_assert(Size <= sizeof...(Ts), "Size out of range");
    static_assert(Index + Size <= sizeof...(Ts), "Index + Size out of range");
};

template <size_t Index, size_t Size, class...Ts>
requires (Index <= sizeof...(Ts) && Size <= sizeof...(Ts) && Index + Size <= sizeof...(Ts))
struct TypePackSubPack<Index, Size, TypePack<Ts...>> :
    TypePackFirstN<Size, typename TypePackSkipN<Index, TypePack<Ts...>>::type> {
};

Validation with static_assert

Our tests ensure that slicing works on empty packs, single-element packs, and larger collections.

TEST(TypePackTests, FirstN0)
{
    using Pack = TypePack<>;
    static_assert(std::is_same_v<Pack::first_n_t<0>, TypePack<>>);
}

TEST(TypePackTests, FirstN1)
{
    using Pack = TypePack<int>;
    static_assert(std::is_same_v<Pack::first_n_t<0>, TypePack<>>);
    static_assert(std::is_same_v<Pack::first_n_t<1>, TypePack<int>>);
}

TEST(TypePackTests, FirstN)
{
    using Pack = TypePack<int, long, double, char>;
    static_assert(std::is_same_v<Pack::first_n_t<0>, TypePack<>>);
    static_assert(std::is_same_v<Pack::first_n_t<1>, TypePack<int>>);
    static_assert(std::is_same_v<Pack::first_n_t<2>, TypePack<int, long>>);
    static_assert(std::is_same_v<Pack::first_n_t<3>, TypePack<int, long, double>>);
    static_assert(std::is_same_v<Pack::first_n_t<4>, TypePack<int, long, double, char>>);
}

TEST(TypePackTests, SkipN0)
{
    using Pack = TypePack<>;
    static_assert(std::is_same_v<Pack::skip_n_t<0>, TypePack<>>);
}

TEST(TypePackTests, SkipN1)
{
    using Pack = TypePack<int>;
    static_assert(std::is_same_v<Pack::skip_n_t<0>, TypePack<int>>);
    static_assert(std::is_same_v<Pack::skip_n_t<1>, TypePack<>>);
}

TEST(TypePackTests, SkipN)
{
    using Pack = TypePack<int, long, double, char>;
    static_assert(std::is_same_v<Pack::skip_n_t<0>, TypePack<int, long, double, char>>);
    static_assert(std::is_same_v<Pack::skip_n_t<1>, TypePack<long, double, char>>);
    static_assert(std::is_same_v<Pack::skip_n_t<2>, TypePack<double, char>>);
    static_assert(std::is_same_v<Pack::skip_n_t<3>, TypePack<char>>);
    static_assert(std::is_same_v<Pack::skip_n_t<4>, TypePack<>>);
}

TEST(TypePackTests, SubPack0)
{
    using Pack = TypePack<>;
    static_assert(std::is_same_v<Pack::subpack_t<0, 0>, TypePack<>>);
}

TEST(TypePackTests, SubPack1)
{
    using Pack = TypePack<int>;
    static_assert(std::is_same_v<Pack::subpack_t<0, 0>, TypePack<>>);
    static_assert(std::is_same_v<Pack::subpack_t<0, 1>, TypePack<int>>);
    static_assert(std::is_same_v<Pack::subpack_t<1, 0>, TypePack<>>);
}

TEST(TypePackTests, SubPack)
{
    using Pack = TypePack<int, long, double, char>;
    static_assert(std::is_same_v<Pack::subpack_t<0, 0>, TypePack<>>);
    static_assert(std::is_same_v<Pack::subpack_t<0, 1>, TypePack<int>>);
    static_assert(std::is_same_v<Pack::subpack_t<1, 1>, TypePack<long>>);
    static_assert(std::is_same_v<Pack::subpack_t<2, 1>, TypePack<double>>);
    static_assert(std::is_same_v<Pack::subpack_t<3, 1>, TypePack<char>>);
    static_assert(std::is_same_v<Pack::subpack_t<0, 2>, TypePack<int, long>>);
    static_assert(std::is_same_v<Pack::subpack_t<1, 2>, TypePack<long, double>>);
    static_assert(std::is_same_v<Pack::subpack_t<2, 2>, TypePack<double, char>>);
    static_assert(std::is_same_v<Pack::subpack_t<0, 3>, TypePack<int, long, double>>);
    static_assert(std::is_same_v<Pack::subpack_t<1, 3>, TypePack<long, double, char>>);
    static_assert(std::is_same_v<Pack::subpack_t<0, 4>, TypePack<int, long, double, char>>);
}

Conclusion

We have now transitioned from merely looking at types to actively reshaping our type containers. By combining recursion with basic "Head/Tail" manipulation, we created a powerful slicing engine that allows us to isolate any subset of types.

In the next part, we will explore how to grow our containers: inserting new elements into a pack and merging multiple packs into one.

The Implementation: size and element_t

To make TypePack useful, we need to provide a way to access its metadata at compile-time. We achieve this by adding a static constexpr size and a template alias for indexing.

template <class... Ts>
struct TypePack : std::type_identity<TypePack<Ts...>> {
    // 1. Determine the number of elements in the pack
    static constexpr size_t size = sizeof...(Ts);

    // 2. Access a specific type by index
    template <size_t Index>
    using element_t = details::TypePackElement<Index, TypePack>::type;
};

1. The size Property

C++ provides the sizeof... operator specifically for parameter packs. It returns a size_t representing the number of types in the pack. By baking this into the TypePack struct, we allow users to check the pack's length without needing to expand it themselves.

2. The element_t Logic (Recursive Traversal)

Accessing an element at a specific index is more complex. Unlike a runtime array, you cannot use Ts[i]. Instead, we must use recursive template specialization to "peel off" types from the front of the pack until we reach the desired index.

Here is the supporting logic (usually placed in a details namespace):

// Primary template
template <size_t Index, class Pack>
struct TypePackElement;

// Base Case 1: Error handling for empty packs or out-of-bounds
template <size_t Index>
struct TypePackElement<Index, TypePack<>> {
    static_assert(AlwaysFalse<std::integral_constant<size_t, Index>>, "Index out of range");
};

// Base Case 2: Found the type (Index is 0)
template <class T, class... Ts>
struct TypePackElement<0, TypePack<T, Ts...>> : std::type_identity<T> {
};

// Recursive Step: Reduce the index and move to the next type
template <size_t Index, class T, class... Ts>
requires (Index > 0 && Index <= sizeof...(Ts))
struct TypePackElement<Index, TypePack<T, Ts...>> : TypePackElement<Index - 1, TypePack<Ts...>> {
};

• How it works: If we ask for index 2 of <int, long, double>, the compiler matches the recursive step. It then looks for index 1 of <long, double>, and finally index 0 of <double>. At index 0, the specialization extracts double as the type.

Validation with static_assert

We use static_assert within our tests to prove that our indexing logic is accurate and that the size constant correctly reflects the pack's length.

TEST(TypePackTests, ElementType)
{
    using Pack = TypePack<int, long, double, char>;

    // Verify the size
    static_assert(Pack::size == 4);

    // Verify self-identity
    static_assert(std::is_same_v<Pack::type, Pack>);

    // Verify individual element access
    static_assert(std::is_same_v<Pack::element_t<0>, int>);
    static_assert(std::is_same_v<Pack::element_t<1>, long>);
    static_assert(std::is_same_v<Pack::element_t<2>, double>);
    static_assert(std::is_same_v<Pack::element_t<3>, char>);
}

Conclusion

By implementing size and element_t, we have turned a raw pack into a structured list that we can navigate. These tools are the building blocks for more advanced operations like searching, filtering, and transforming packs.

In the next part, we will look at how to extract subsets of our TypePack: retrieving the first N elements, the trailing elements, or a specific range of types.

To harness the power of these packs, we need a way to "capture" them, move them around, and manipulate them without immediate expansion. This is where TypePack comes in.

The Problem: Why Can't We Just Use Packs?

A pack of types is not a first-class citizen in C++. You cannot store a pack in a variable, nor can you create a using alias for a raw pack.

Consider the following illegal code:

template <typename... Ts>
struct Error {
    using MyPack = Ts...; // ERROR: A parameter pack cannot be used as an alias
};

Because of this limitation, if you want to pass a collection of types to another metafunction or store them for later use, you must wrap them in a container.

The std::tuple Example

The most common example of a pack container in the Standard Library is std::tuple.

// std::tuple "captures" the pack Ts into a single type
std::tuple<int, double, char> myData;

While std::tuple is great for storing values of different types, it carries overhead because it’s a concrete class designed for runtime use. For pure compile-time metaprogramming, we need something lighter—a "type-only" container.

The Implementation: TypePack

TypePack is a minimalist structure designed to hold a pack of types. It inherits from std::type_identity to make it easier to refer to the pack's own type in complex transformations.

#include <type_traits>

template <class... Ts>
struct TypePack : std::type_identity<TypePack<Ts...>> {
    // This structure intentionally has no data members.
    // Its only purpose is to carry the pack 'Ts...' in its signature.
};

By wrapping Ts... inside TypePack, the pack becomes part of a single, concrete type. You can now pass this TypePack to other templates, nest it, or return it from a metafunction.

Validation and Examples

To ensure our TypePack behaves as expected, we can use static_assert. These tests verify that different instances of TypePack are recognized as unique types and that they correctly inherit their own identity.

// 1. Verify that empty packs are valid
using EmptyPack = TypePack<>;
static_assert(!std::is_same_v<EmptyPack, TypePack<int>>);

// 2. Verify identity inheritance
using MyTypes = TypePack<int, float, double>;
static_assert(std::is_same_v<MyTypes::type, MyTypes>);

// 3. Nested TypePacks (TypePacks can hold other TypePacks)
using Nested = TypePack<TypePack<int, int>, char>;
static_assert(std::is_same_v<Nested::type, TypePack<TypePack<int, int>, char>>);

Conclusion

TypePack is the foundation of our library. By wrapping a variadic pack into a struct, we bypass the language limitations that prevent us from treating packs as entities. We have moved from a raw, "unstable" pack to a stable, nameable type.

In the next part, we will explore how to calculate the size of a TypePack and how to get individual types from it.

With C++20 Concepts, the game has changed, allowing us to express intent more clearly than ever. Today, I want to share a pattern I find particularly useful: the IsSpecializationOf concept.

The Challenge

If you want to sum a std::vector of any numeric type, you might start with a basic template. While it works, things get complicated when you need to handle multiple vectors of different types simultaneously or restrict template arguments to specific container shapes.

To gain more control, we need a way to check if a type is a specialization of a specific template (like std::vector).

The Implementation

#include <vector>
#include <numeric>

template <typename T>
auto sum_vector(const std::vector<T>& vec) -> T {
    return std::accumulate(vec.begin(), vec.end(), T{});
}

namespace details {
    // Primary template: defaults to false
    template <class, template <class...> class>
    inline constexpr bool isSpecializationOf = false;

    // Partial specialization: matches if the type is Template<Ts...>
    template <template <class...> class Template, class... Ts>
    inline constexpr bool isSpecializationOf<Template<Ts...>, Template> = true;
} // namespace details

// The C++20 Concept
template <class T, template <class...> class Template>
concept IsSpecializationOf = details::isSpecializationOf<T, Template>;

// Constrain the parameter pack to only allow std::vector specializations
auto sum_all_vectors(const IsSpecializationOf<std::vector> auto& ... vecs)
// Ensure all vectors contain arithmetic types (int, float, etc.)
requires ((std::is_arithmetic_v<typename std::decay_t<decltype(vecs)>::value_type> && ...)) {
    // Use a fold expression to sum everything into a double
    return (std::accumulate(vecs.begin(), vecs.end(), 0.0) + ...);
}

// Usage:
std::vector<int>    v1{1, 2};
std::vector<float>  v2{3.5f, 4.5f};
std::vector<double> v3{10.0, 20.0};

double total = sum_all_vectors(v1, v2, v3); // Result: 41.0

Why I love this approach:

• Intent-Based Programming: Your function signature explicitly states: "I only accept things that are specializations of std::vector."

• Variadic Beauty: It leverages fold expressions and concepts to handle an arbitrary number of containers cleanly.

• Better Errors: If you accidentally pass a std::list, the compiler gives a clear error about the failed concept requirement rather than a cryptic error deep inside the function body.

Are you exploring C++20 Concepts in your current projects? What are your favorite metaprogramming patterns? Let's talk in the comments!

First introduced by Alexandr Poltavsky in 2017, this technique opened the door to advanced type introspection, such as extracting member types from structs, creating compile-time type lists, or implementing custom memory layouts for tuple-like structures — all without relying on compiler extensions.

How it works

The loophole exploits the fact that a friend function can be declared in a template class and later defined by an instantiation of another template. Because the definition happens during template instantiation, it can "capture" a type provided at that moment and make it available for later retrieval via ADL (Argument Dependent Lookup).

While the original implementation is notoriously difficult to read, here is a modernized, C++20-ready version that provides a cleaner interface for everyday metaprogramming.

Implementation

#include <string>
#include <type_traits>

struct Loophole final
{
    // Decl: Generates a friend declaration with an 'auto' return type.
    // This act creates the "slot" where the type will be stored.
    template <class>
    struct Decl final
    {
        friend auto loophole(Decl key);
        consteval friend auto loopholeDetect(Decl key) noexcept;
    };

    template <class T>
    struct ReturnType final : std::type_identity<T> {};

    // Def: Instantiates the friend functions.
    // This "plugs" the type into the previously declared slot.
    template <class Key, class Value, bool IsDefined>
    struct Def final
    {
        friend auto loophole([[maybe_unused]] const Decl<Key> key)
        {
            return ReturnType<Value>{};
        }

        consteval friend auto loopholeDetect([[maybe_unused]] const Decl<Key> key) noexcept
        {
            return true;
        }
    };

    // Specialization to prevent multiple-definition errors
    template <class Key, class Value>
    struct Def<Key, Value, true> final {};

    template <class Key>
    struct Setter
    {
        template <class T> static int helper(...);
        template <class T, bool = loopholeDetect(T{})> static char helper(int);

        // This method is used in a non-evaluated context to trigger instantiation
        template <class Value,
                  int = sizeof(Def<Key, Value, sizeof(helper<Decl<Key>>(0)) == sizeof(char)>)>
        static consteval void set() {}
    };

    template <class Key, class Value>
    static consteval void set()
    {
        Setter<Key>::template set<Value>();
    }

    // Value: Retrieves the stored type by calling the 'loophole' function
    template <class Key>
    using Value = typename decltype(loophole(Decl<Key>{}))::type;
};

// Unique tags for different loophole instances
template <class T, size_t Index>
struct Tag;

int main() 
{
    using Key = Tag<std::string, 0>;
    using Value = int;

    // Capture the relationship at compile time
    Loophole::set<Key, Value>();

    // Retrieve the relationship later
    static_assert(std::is_same_v<Loophole::Value<Key>, Value>);
}

Why use this version?

1. Safety: It uses consteval and std::type_identity to ensure all operations happen at compile time without runtime overhead.

2. C++20 Cleanliness: Leveraging modern template mechanics makes the "detection" phase (checking if a type is already set) more robust.

3. Readability: The separation into Decl, Def, and Setter makes the logical flow of "Declare -> Check -> Define" much easier to follow.

Sources

• Alexandr Poltavsky: C++ Type Loophole

• Deni64k: Simplified Reflection Gist

iVentoy takes this concept to the next level: it allows you to boot and install operating systems on multiple machines over the network with virtually zero configuration. The workflow is just as simple—drop your ISO files into a folder and select PXE boot on the client machine.

Here is how I deployed iVentoy using Docker to streamline my home lab.

1. Router Configuration (OpenWrt)

To make PXE work, your network needs to know where the boot server is. I configured the dnsmasq DHCP server on my OpenWrt router to provide the necessary PXE parameters to all devices.

Add the following to your /etc/config/dhcp (or via LuCI):

config boot
    option servername 'server'
    option serveraddress '192.168.1.20' # IP of your iVentoy host
    option filename 'iventoy_loader_16000'

2. Crafting the Docker Image

I created a lightweight Docker image based on Debian to host the iVentoy binaries.

Dockerfile:

FROM debian:bookworm-slim
ARG IVENTOY_VER=1.0.19

# Download and extract iVentoy
ADD https://github.com/ventoy/PXE/releases/download/v$IVENTOY_VER/iventoy-$IVENTOY_VER-linux-free.tar.gz /tmp/iventoy.tar.gz
RUN tar -xf /tmp/iventoy.tar.gz -C /opt && \
    mv /opt/iventoy-$IVENTOY_VER /opt/iventoy

VOLUME /opt/iventoy/iso
# Ports for DHCP, TFTP, NBD, and Web UI
EXPOSE 68/udp 69/udp 10809/tcp 16000/tcp 26000/tcp

ENTRYPOINT ["bash", "-c", "cd /opt/iventoy && ./iventoy.sh -R start && sleep 5 && tail -f log/log.txt"]

3. Deployment with Docker Compose

Using docker-compose makes managing the volumes and network modes much easier. Note that network_mode: host is critical for PXE to intercept DHCP requests correctly.

docker-compose.yml:

version: "3.7"

services:
  iventoy:
    image: iventoy
    build: . # Path to the Dockerfile
    container_name: iventoy
    restart: unless-stopped
    privileged: true
    cap_add:
      - NET_ADMIN
    hostname: iventoy
    network_mode: host
    volumes:
      - /share/Boot-Images:/opt/iventoy/iso:ro
      - /share/container-data/iventoy/config.dat:/opt/iventoy/data/config.dat

4. Management and Testing

Once the container is running, the web interface is accessible at http://<your_ip>:26000. From there, you can customize the boot screen, manage ISOs, and adjust deployment settings.

I tested this setup by booting an openSUSE installation ISO on a Proxmox VM. The client picked up the IP, loaded the iVentoy menu, and started the installation flawlessly!

Conclusion

If you frequently reinstall operating systems or manage a home lab, iVentoy is a must-have. It eliminates the need for physical USB sticks and makes OS deployment as simple as copying a file.

1. Prerequisites

First, ensure you have the latest versions of the essential components installed:

• Windows Terminal (available via Microsoft Store or GitHub).

• PowerShell Core (pwsh): The cross-platform version of PowerShell is faster and more feature-rich than the built-in Windows PowerShell.

2. Profile Configuration

Organize your profiles in the Windows Terminal settings (Settings > Startup).

• Set Default Profile: Set PowerShell Core as your default.

• Ordering: Place your most-used environments at the top. For instance, I keep PowerShell Core first and my WSL distribution (openSUSE Tumbleweed) second. This allows for quick access via Ctrl+Shift+1, Ctrl+Shift+2, etc.

3. Typography and Nerd Fonts

To render icons and glyphs correctly in the terminal, you need a Nerd Font (patched fonts containing extra symbols).

1. Download a font from Nerd Fonts. My personal favorites are Cascadia Code and JetBrains Mono.

2. Install the font and set it in Windows Terminal: Settings > Profiles > PowerShell > Appearance > Font face.

4. Essential PowerShell Plugins

Run these commands in PowerShell Core to install the core productivity stack:

a) Oh-My-Posh (Theming engine)

winget install JanDeDobbeleer.OhMyPosh

b) Posh-Git (Git status in your prompt)

Install-Module posh-git -Confirm:$False -Force

c) Terminal-Icons (Adds icons to ls / dir outputs)

Install-Module Terminal-Icons -Confirm:$False -Force

d) PSFzf (Fuzzy search for files and history)

winget install junegunn.fzf
Install-Module PSFzf -Confirm:$False -Force

e) Zoxide (A smarter cd command)

winget install ajeetdsouza.zoxide

5. Configuring Oh-My-Posh

Initialize Oh-My-Posh to see available themes:

oh-my-posh init pwsh | Invoke-Expression
Get-PoshThemes

You can choose from dozens of built-in styles. Personally, I use a custom modified version of the "hotstick.minimal" theme.

6. Finalizing Your Profile Script

The PowerShell profile is a script that runs every time you start the terminal. Open it by typing:

notepad $PROFILE

Paste your configuration into this file. You can use my reference profile here as a template. Make sure to update the theme initialization line:

# Example theme initialization
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH/mytheme.omp.json" | Invoke-Expression

# Add your custom aliases here
Set-Alias v nvim

Key Benefits of This Setup

By following these steps, your terminal will support:

• Rich Visuals: A prompt showing Git branch status and execution time.

• Visual File Navigation: Colorful icons in file listings.

• Intelligence: Suggestions based on your command history.

• Speed: Fuzzy search for files (Ctrl+F) and history (Ctrl+R).

• Efficiency: Smart directory jumping with the z command and custom aliases.

For this experiment, I chose the 1991 film "Only Yesterday". It is notoriously difficult to transcode due to persistent picture jitter and film grain (noise). Using FFmpeg 6.0, I compared HEVC and AV1, finding that a 10-bit depth and Constant Rate Factor (CRF) yielded the best results for both.

The Results

The AV1 encode was remarkably four times smaller (645 MB) than the HEVC version (2563 MB), despite maintaining nearly identical quality metrics. However, the trade-off was encoding time: using libaom, it took approximately three days to process the two-hour movie.

Encoding Parameters

HEVC (x265):

-c:v libx265 -preset slow -tune animation -profile:v main10 -pix_fmt yuv420p10le -crf 22 -x265-params crf=22:no-sao=1:no-fast-intra=1

AV1 (libaom):

-c:v libaom-av1 -pix_fmt yuv420p10le -b:v 0 -crf 30 -threads 8 -cpu-used 4 -aq-mode 1 -tune ssim -lag-in-frames 35 -arnr-max-frames 15 -arnr-strength 4 -aom-params tune=ssim:cq-level=30:cpu-used=4:noise-sensitivity=2:tune-content=default:arnr-strength=4:arnr-maxframes=15:enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1

Quality Metrics Comparison

The metrics confirm that AV1 achieved the same visual fidelity as HEVC while using only 25% of the disk space. For archival purposes where storage is at a premium and encoding time is not a concern, AV1 is the clear winner.