Namespaces; The Secret Formula For Apple’s Rounded Corners; Just Go Already

We’ve got a theme for the week! The first section will carry over W-F to avoid overwhelming a single issue with a nerdy topic. I’m pretty sure the middle section will be a nice distraction from the news for most folks, even if you aren’t a fa of Apple.

Aside: 47 Watch had some major updates over the weekend. I managed to get 46 nominees researched, swapped in a new-but-familiar full-text search engine with a slightly better UX, and made it a tad more mobile friendly. The “Analysis” tab will be tracking and analyzing outcomes/aftermaths (like the head-spinning Colombia tariff-no-tariff debacle) as well. The repo is also collecting miscellaneous, related PDFs, and there’s a separate “Cowards & Collaborators” markdown file that will have names added to it as each official demonstrates their lack of will to do the right thing.

TL;DR

(This is an AI-generated summary of today’s Drop using Ollama + llama 3.2 and a custom prompt.)

• Linux namespaces enable process isolation and resource partitioning, serving as the foundation for container technologies with features like PID, Network, Mount, IPC, and UTS namespaces (https://man7.org/linux/man-pages/man7/pid_namespaces.7.html)
• Apple’s rounded corners design philosophy follows a systematic pattern based on device proximity to users, ranging from 0% roundness for desktop devices to 64% for wearables, using complex “squircle” curves (https://arun.is/blog/apple-rounded-corners/)
• Go 1.24, releasing February 2025, introduces performance improvements with Swiss Tables-based maps, new os.Root type for filesystem control, and generic type aliases for better code organization (https://tip.golang.org/doc/go1.24)

Namespaces

Linux namespaces are a kernel feature that enables process isolation and resource partitioning. They serve as the backbone of modern containerization technologies like Docker, Podman, or systemd-nspawn (which we’ll see Thursday). Understanding namespaces becomes increasingly relevant as software development moves toward containerized applications and microservices architectures. And, even if you’re just a casual user of containers (via any container management idiom), knowing a bit more about them may come in handy some day.

The “PID namespace” creates an isolated process tree where processes can only see other processes within their namespace. When a new PID namespace is created, the first process gets PID 1, similar to the init system, and becomes responsible for handling orphaned processes within that namespace.

User namespaces provide privilege isolation by mapping user and group IDs between the host system and the namespace. This allows processes to have root privileges within their namespace while remaining unprivileged on the host system, making it possible to safely run containerized applications with elevated permissions.

Mount namespaces isolate the filesystem mount points, allowing processes to have their own view of the filesystem hierarchy. This isolation ensures that changes to mount points within a namespace don’t affect the host system or other namespaces.

Network namespaces provide isolated network stacks, including separate network interfaces, routing tables, and firewall rules. This isolation is crucial for container networking and allows multiple applications to use the same port numbers without conflict.

IPC (Inter-Process Communication) namespace ensure that applications running in different containers cannot accidentally or maliciously interfere with each other’s communication channels.

UTS (Unix Timesharing System ) namespaces allow containers to maintain their own identity through unique hostnames, which is crucial for applications that rely on hostname information for proper functioning.

There are more, but these are some of the most common ones you’re likely to directly encounter.

You’ve used namespaces whenever you’ve incanted docker run CONTAINERNAME at a command line. Upon execution Docker automatically creates a new set of namespaces specifically for that container. This process happens transparently as part of Docker’s core functionality for container isolation. (Substitute “Docker” with an container manager tech.)

When you run a container, Docker creates five default namespaces:

• PID
• Network
• Mount
• IPC
• UTS

When your container starts, the first process inside gets assigned PID 1 within the container’s namespace, while on the host system it has a different PID number. This isolation ensures that processes inside the container can’t see or interact with processes outside their namespace.

While Docker creates separate namespaces by default, you can explicitly share namespaces between containers. For example, you can run a debugging container in the same PID namespace as your application container using the --pid flag. This capability is particularly useful for troubleshooting, as it allows diagnostic tools in one container to inspect processes running in another container.

The namespace creation process is a core security feature that provides the isolation necessary for containers to run safely and independently on the same host system. Each container gets its own isolated workspace, ensuring that resources and processes remain separate from both the host system and other containers.

To show an example of how two containers can work together in the same namespace, we can start up and nginx web server container, then run a completely different container in the same namespace and try to access the web server via curl:

$ docker run --name webserver -d nginx # we use an explicit `name` so we can reference it later

Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
7ce705000c39: Pull complete
b3e9225c8fca: Pull complete
2b39a3d0829e: Pull complete
6d24e34787c7: Pull complete
066d623ff8e6: Pull complete
49486a4a61a6: Pull complete
34d83bb3522a: Pull complete
Digest: sha256:0a399eb16751829e1af26fea27b20c3ec28d7ab1fb72182879dcae1cca21206a
Status: Downloaded newer image for nginx:latest
aa0f88d118ff26138d3a6298289912923bcb7ede05e9b34fcfcb083b3973565c

Now, we’ll use a very thin container and leave us at a shell:

$ docker run -it --network=container:webserver alpine sh

Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
52f827f72350: Pull complete
Digest: sha256:56fa17d2a7e7f168a043a2712e63aed1f8543aeafdcee47c58dcffe38ed51099
Status: Downloaded newer image for alpine:latest
/ # apk add curl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.21/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.21/community/aarch64/APKINDEX.tar.gz
(1/9) Installing brotli-libs (1.1.0-r2)
(2/9) Installing c-ares (1.34.3-r0)
(3/9) Installing libunistring (1.2-r0)
(4/9) Installing libidn2 (2.3.7-r0)
(5/9) Installing nghttp2-libs (1.64.0-r0)
(6/9) Installing libpsl (0.21.5-r3)
(7/9) Installing zstd-libs (1.5.6-r2)
(8/9) Installing libcurl (8.11.1-r0)
(9/9) Installing curl (8.11.1-r0)
Executing busybox-1.37.0-r9.trigger
OK: 12 MiB in 24 packages
/ # 

Now, curl the nginx web server:

/ #  # curl localhost
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
/ #

You can use exit or ^d get out of that Alpine container.

On Wednesday (barring $WORK DoS), we’ll get an overview of the diverse options for container management (the world is bigger than Docker, and if you’ve suspected I’m trying to socially engineer you to stop using Docker, you’re right!).

The Secret Formula For Apple’s Rounded Corners

In “The Secret Formula For Apple’s Rounded Corners“, Arun Venkatesan takes us journey into Apple’s product design, focusing on one aspect which we’ve all likely taken for granted at this point: those ever-present rounded corners.

Apple’s product design philosophy follows a sophisticated approach to rounded corners that reflects both functional and psychological considerations. The heart of this design strategy is the relationship between an object’s proximity to human interaction and its degree of roundness.

Rounded corners serve multiple practical purposes — they reduce the risk of injury, enhance durability against drops and impacts, and trigger positive psychological responses. Research shows that sharp angles activate the amygdala, the brain’s fear processing center, while rounded objects are perceived more favorably.

The degree of roundness in Apple products follows a clear pattern based on how closely humans interact with the device:

• Desktop devices (Mac Pro, Mac mini): 0% roundness
• Displays and iMacs: 2-3% roundness
• MacBooks: 7-10% roundness
• iPads: 12-18% roundness
• iPhones: ~33% roundness
• Wearables and accessories (AirPods, Apple Watch): 48-64% roundness

Apple doesn’t use simple circular curves but rather employs “squircles” — complex mathematical curves that create seamless transitions between straight edges and corners. This attention to detail ensures there’s no visible point where the straight line ends and the curve begins.

The roundness is calculated by measuring the diameter of the curve (twice the radius) divided by the length of the device’s shorter side, expressed as a percentage. This systematic approach ensures consistency across the entire product line while maintaining appropriate proportions for each device category.

The design philosophy extends to Apple’s newest products, including the ill-fated Vision Pro, which features extensive curvature to maintain consistency with its close proximity to the user’s face. This mathematical precision and thoughtful implementation of rounded corners has become a signature element of Apple’s industrial design language (though it didn’t help the Vision Pro overcome the lack of product market fit).

Arun has far more detail and great visual examples. Go give it a read!

Just Go Already

The Go programming language has consistently evolved, and the upcoming Go 1.24, releasing in February 2025, is poised to be one of the most impactful updates yet.

Go’s runtime has seen some optimization, and most of your Go program will see a 2-3% reduction in CPU overhead. The main reason for this is a spiffy new Swiss Tables-based map implementation (Map types are unordered collections of key-value pairs). The performance boost also comes from a refined small object memory allocation and enhanced the internal mutex implementation.

As someone who has increasingly been using Deno alongside Go for the past 18 months, Go’s new os.Root type is a familiar and welcome addition. One reason I like Deno is that you can provide fine-grained access control to Deno runtime binaries. Go seems to have channeled a bit of that, and now provides fine-grained control over filesystem operations. This can help prevent unauthorized access beyond specified directories in the event of a compromised Go process.

Generic type aliases are finally here, bringing more flexibility to parameterized types. This solves a common problem in large-scale Go codebases by enabling seamless refactoring of generic types across packages. When moving types between packages during reorganization, developers can now maintain complete type compatibility without breaking existing code.

For those working with private modules, the new GOAUTH feature streamlines authentication, while improved JSON output support for build and test commands makes hooking Go into automation and observability frameworks much easier. Even the humble go.mod file gets some love with new tool directives for tracking executable dependencies.

It’s worth noting that this release does come with some platform-specific changes. Linux users will need kernel 3.2 or later, and macOS Big Sur users should pay attention as this will be the last release supporting their platform. Windows ARM users should also be aware that the windows/arm port is currently marked as broken (but, Windows is a broken OS to begin with).

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

Also, refer to:

• this post, and
• this post

to see how to access a regularly updated database of all the Drops with extracted links, and full-text search capability. ☮️