If someone asked me the question "what layout should I use for my Go code repository?", I'd start by asking back "what are you building: an executable, or a library?"
Create a directory named however you want your final executable to be called (e.g. "mycommand"), change into that directory, and create the following files:
Updated 2025-05-31
| [gomock][1] | [testify][2] + [mockery][3] | [mockio][4] | [minimock][5] | [moq][6] | |
|---|---|---|---|---|---|
| GitHub stars | [![s1]][1] | [![s2]][2] + [![s3]][3] | [![s4]][4] | [![s5]][5] | [![s6]][6] |
| Latest release date | [![d1]][r1] | [![d2]][r2] + [![d3]][r3] | [![d4]][r4] | [![d5]][r5] | [![d6]][r6] |
| Maintained | ✅ | ✅ | ✅ | ✅ | ✅ |
Wayland breaks everything! It is binary incompatible, provides no clear transition path with 1:1 replacements for everything in X11, and is even philosophically incompatible with X11. Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.
Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.
Deterministic docker-network to container interface is a must in multi-network setups Docker-compose has a priority mechanism to let the containers connect in order to the given networks
However, docker itself doesn't seem to take that into account
Instead, ethX order in the containers is determined by the lexical order of network names
| package main | |
| import ( | |
| "bytes" | |
| "flag" | |
| "golang.org/x/net/websocket" | |
| "io" | |
| "k8s.io/client-go/1.4/rest" | |
| "k8s.io/client-go/1.4/tools/clientcmd" | |
| "log" |
