On Prometheus and Grafana after a year ,a commentator asked some good questions:

Is there a reason why you went with a "metrics-based" (?) monitoringsolution like Prometheus-Grafana, and not a "service-based" systemlike Zabbix (or Nagios)? What (if anything) was being used before thecurrent P-G system?

I'll start with the short answer, which is that we wanted metrics aswell as alerting and operating one system is simpler than operating two,

We started up our permanent production Prometheus instance on November 21st of 2018, which meansthat it's now been running and saving metrics for over a year (actuallyover 13 months by now, because I'm bad at writing entries on time). OurPrometheus and Grafana setup hasn't been static over that time, but italso hasn't undergone any significant changes from our straightforwardinitial setup (which was essentially the same as our current setup , just with fewer additional

I have written a fair amount about Prometheus ,but I've never described how our setup actually looks in terms ofwhat we're running and where it runs. Even though I feel that oursetup is straightforward and small scale as Prometheus setups go, there's some value in actuallywriting it down, if only to show how you can run Prometheus in amodest environment without a lot of complexity.

The main Prometheus programs and Grafana all are on a single Dell 1U server (currently a Dell R

To fully implement system call origin verification , OpenBSD would like Go to makesystem calls through the C library instead of directly making systemcalls from its own runtime (which it has some reasons for doing ). On the surface, this sounds likeonly a moderately small issue; sure, it's a bit awkward, but alanguage like Go should be able to just make calls to the usual Clibrary functions like open() (and using the C calling ABI).Unfortunately it's not that simple

When I updated my office workstation to Fedora 30 back in August, I ran into a little issue :

It has been '0' days since systemd/udev blew up my networking. Fedora30 systemd/udev attempts to rename VLAN devices to the interface'sbase name and fails spectacularly, causing the sys-subsystem*.deviceunits to not be present. We hope you didn't depend on them! (I did.)

I filed this as Fedora bug #17416

One of the recent pieces of news in the Unix world is that as partof its general security work, OpenBSD is moving towards only allowingsystem calls to be made from the C library, not from any other code(you can read about this in OpenBSD system call origin verification ). Right now OpenBSD has anexemption for the code of programs themselves, primarily becauseGo generally makes system calls directly instead of by calling theC library, but they would like to get rid of that. Other people arenot happy

I said yesterday that both the BSD 'basesystem' approach and the Linux distribution 'assemblage of parts'approach to building systems each have their own advantages. Oneof the large scale differences between the two approaches is whatwinds up being relatively coherent and unified.

In the BSD approach where the base system is all developed by asingle group under its own control, the base system is coherent andunified among almost all of the various parts (and exceptions tendto stick out and be awkward, like GCC).

I recently read John Goerzen's The Fundamental Problem in Python3 ,which talks about Python 3's issues in environments where filenames(and other things) are not in a uniform and predictable encoding.As part of this, he says:

[...]. Critically, most of the Python standard library treats afilename as a String – that is, a sequence of valid Unicode codepoints, which is a subset of the valid POSIX filenames.

[...]

From a POSIX standpoint,

OpenBSD has a well deserved reputation for putting security and aclean system (for code, documentation, and so on) first, andeverything else second. OpenBSD is of course based on BSD (it'sright there in the name) and descends from FreeBSD NetBSD (you can read the history here ). But one of the questionsyou could ask about it is whether it had to be that way, and inparticular if you could build something like OpenBSD on top ofLinux. I believe that the answer