Hacker News Reader

> I can't help but think that their reluctance to use Docker feels contrarian for no reason

My impression is that it's less about contrarianism and more about

1. the developer opting for installation instructions being consistent across both of the intended targets (Linux and (Open)BSD); and/or

2. μMon being allegedly tiny and simple enough that you're probably best off stuffing it into every one of your containers anyway (i.e. so that said containers can expose their own monitoring interfaces) instead of having a dedicated container for it

> There's an argument to be made that the "Simple" Network Management Protocol they're a fan of is far from being simple either[2]. Configuring the security features of v3 is not a simple task, and entire books have been written about SNMP as well. They conveniently ignore this by using v2c and making access public, which might not be acceptable in real-world deployments.

Agreed here. If SNMP is supposed to be "simple", I'd hate to see what the Complex Network Management Protocol looks like!

(I have a similar peeve about LDAP, on that note; I guess compared to wrappers around it like Active Directory and FreeIPA it's "lightweight", but I dread imagining what a heavyweight directory access protocol would entail)

Both of those are based on old OSI protocols, which were terrifying in their complexity. LDAP mostly subsetted DAP and X.500 and added Internet concepts. SMNP leveraged ASN.1 with some ideas from CMIP but using Internet concepts and attention paid to operations when the network is marginal (unlike CMIP)

"What do you get when you cross a mobster with an OSI standard?

You get someone who makes you an offer you can't understand."

> There's an argument to be made that the "Simple" Network Management Protocol they're a fan of is far from being simple either[2]. Configuring the security features of v3 is not a simple task, and entire books have been written about SNMP as well. They conveniently ignore this by using v2c and making access public, which might not be acceptable in real-world deployments.

Oh you sweet summer child that's fucking easiest part of this utter abomination!

Adding anything that's not covered by standard OIDs is a fucking chore. And it is just a string of numbers so you either have to write your own custom OID files and distribute them everywhere OR operate by numbers alone.

And there is no fucking key-value or even fucking labels. If you want to have say distribute a list of arbitrary keys with arbitrary values under hierarchy, the OID will look like

    .1.1.1.1.1: key1
    .1.1.1.1.2: key2
    .1.1.1.1.3: key3
    .1.1.1.2.1: val1
    .1.1.1.2.2: val2
    .1.1.1.2.3: val3

It was created for devices with tens or hundreds kB of RAM that couldn't handle caring about descriptive protocol but it should be dead 20 years ago

This is what MIBs are for. Like yeah MIBs are probably too verbose for what they're used for, but once you write yours you only need it on the host you'll make snmp gets from (ie your monitoring host) the snmp client will then use it to translate it to an OID and bobs your uncle.

What i do is that i use a custom private OID in the apropriate range, and then sub-OIDs in that range get passed to a shell script that finds and executes the appropriate commands (generally one-liners) for that sub-OID. As soon as i add a sub-OID, i also add it to the MIB, which has support for descriptions upon descriptions on top of type info.

When i read that they thought docker was outdated I figured i would open the repo to find go code and pre built binaries… when i found c++ i was left thinking the same as you.

If it's simple doesn't need docker, and as someone else said you might even want to stuff it into your docker containers.. so a minimal thing doesn't need docker imo. The simple landscape is huge, same as for whether one believes that C++ is outdated or not ;) Guess figure what is easier to get up and run still on many platforms.. simple C/C++, or anything else?

Docker can be used to provide a plug and play Development environment, even if the result isn't deployed into production as a container.

C++ projects I expect would benefit even more than most from such configurations, reducing the barrier for entry of new contributors by eliminating the environment bootstrap headaches

> Docker feels contrarian for no reason

No, Docker is a mess.

Docker may be a terrible mess, sure, but something something VC.

What is it more specifically that you think is a mess? Do you mean the OCI Image Format, Docker Inc, Docker Engine, something else…?

I couldn’t get Docker to run with WSL backend on a freshly installed Windows 11 Pro, a very common use case.

I’m not sure if they even test their own software.

Windows and WSL are a mess. Run docker on Linux instead. There is no reason to run docker on windows, except if you are planning to build windows containers.

If you're a Windows user, running Docker in WSL _is_ running it in Linux.

Yes, Linux wrapped into countless unnecessary abstraction layers.

Incorrect. Portable .NET development natively uses Docker. Works pretty seamlessly with Visual Studio actually, though slower than I'd like.

Funny that, WSL2 on Windows 11 with Linux containers works nearly perfectly for me (I think the only thing that'd make it better is another 8 GB or so of RAM), with using devcontainers, building images and running Docker compose - it's the Windows containers that cause the trouble, mostly with networking

You could just opt for the regular Docker for Windows approach, instead. Although I honestly only ran Docker in WSL on Windows, but haven't tried with Windows 11.

You enumerated it yourself.

I agree that the naming of the different entities is not very clear. That doesn’t imply that each of these entities is a mess though.

Not sure if I'd count "OCI Image Format" under the Docker umbrella, since Docker doesn't actually follow it. Also, slight nitpick, but "OCI Image Format" is itself a bit of an umbrella, since there are images, manifests, layers, etc. It's easy enough to make a standards-compliant image using `tar`, `sha256sum` and `jq`, but it's rather hit-and-miss which tools will support it (e.g. AWS seems easy to please, but nerdctl rejects certain things, etc.)

Personally, my main problems with Docker are:

- Dockerfiles: these are basically just shell scripts, which throws away decades of improvements and leads to all sorts of insanity (e.g. running `apt install -y foo bar baz`, rather than making a .deb which depends on those). It also causes everything to happen "inside-out", with our compiler toolchains, etc. getting installed inside the container (requiring even more containers to try and extricate the build products, and so on)

- Docker Inc: specifically, their over-complication of basic shit, as a way to funnel everything through themselves. Want to u̵p̵l̵o̵a̵d̵ push your t̵a̵r̵ ̵f̵i̵l̵e̵ image to a r̵e̵m̵o̵t̵e̵ ̵d̵i̵r̵e̵c̵t̵o̵r̵y̵ registry? No rsync for you: not only will you need to run the `docker` command, but it must be "logged in" first (??!); oh, and you'll need to pass credentials over stdio (hooray for the /proc filesystem!). Note that this is just my experience from using private f̵o̵l̵d̵e̵r̵s̵ registries (e.g. like https://docs.aws.amazon.com/AmazonECR/latest/userguide/docke... ). Fun fact: AWS provide a multipart upload API for u̵p̵l̵o̵a̵d̵i̵n̵g̵ pushing to a b̵u̵c̵k̵e̵t̵ registry, which uses the normal AWS credentials chain; so you can just whack a loop around that to u̵p̵l̵o̵a̵d̵ ̵f̵i̵l̵e̵s̵ push images without any `docker login` bullshit ;)

Oh also, Docker Desktop for Mac is the only software I've used which makes the "ignore" button on update nags a "premium feature" (whilst simultaneously making it hard to actually update, since they only publish new binaries to a mutable "latest" URL, hence breaking its SHA256 and hoping people don't mind downloading random ever-changing binaries; the only stable URLs they provide are for "archived" versions, so no wonder I keep getting update nags.... urgh, I eventually just nuked the lot)