This article? Not at all. Does you need to understand D-Bus to use systemd? Not at all. It is just implementation detail. I have an idea to leverage that in future to slap distributed service management on top of systemd, but in normal operations you will probably never spot that everything is D-Bus backed.
No, because these states are set on shutdown, and processes are killed in reverse order. So first the `draining` message will be set and then `drained`.
Author here. If you have any questions, then you can feel free.
My goal there was to provide simplest possible proxy that would allow me to dynamically add and remove the applications from the system during development. It provides passthrough TLS proxying as well as TLS terminating proxy. TLS terminating proxy will automatically create self-signed certificate (in future it will allow defining CA certificates as well as it should support working as ACME CA).
For creating sockets for services it uses systemd-compatible interface where there is FD passed down to the spawned process, this approach allows it to “simulate” socket-activated processes (which are IMHO great idea).
I assume that there is control character after carriage return that deletes everything from there to the EOL, so this do not break copy functionality or "go to EOL" shortcuts.
Oh, I just saw your reply after posting my own, though you beat me to it by quite some margin of time. That's correct, fish sends ^[[K to clear to the EOL after correctly setting the cursor position via this hack to erase any evidence of the hack and for posterity of your ptty contents.
Fantastic rabbit hole to dive into, thanks for linking!
The "good news" is that you can't even use tput rev under fish because it saves and restores attributes each time it regains control of the tty with very few exceptions , rev not being one of them. You can't break what you don't even support!
(Seriously though, we should add rev support.)
EDIT: I just saw that you're the same person that answered that post, which very much deserved the upvote. Your knowledge of tty behavior is impressive. It is also rare to find another person that cares about the kvt - a lot of apps that manipulate terminal attributes or use any vte codes are completely broken under even the well-written kernel virtual terminals.
If you want another rabbit hole with respect to supporting attributes, consider that the Windows Terminal people are considering adding ECMA-48 standards conformance that no other terminal emulator has, the various graphic renditions from ECMA-48:1991 that no-one else has implemented in 30 years. (I saw the issue and added overline, framed, and encircled to my terminal emulator's framebuffer front-end. It will be in version 1.41 of the toolset, but that is not out yet.)
It brought me up short to be described as caring about KVTs. (-: I've mooted doing VTs in application mode code for a couple of decades, now. Here's a white paper from 2006, which was several years in.
Unless you want to implement that on top of your custom structure, like, for example, b-tree. Then you either need to write N different implementations for each separate tree or you need to use `interface{}`.
Yes, custom containers are one place that generics are very useful.
Go has the most useful containers built in. Most code I write doesn't need custom containers, even in languages with templates (I write far more C++ and Java than Go) -- so I find that I don't miss them much when I spend time in Gopherspace.
The most egregious missing container is "set", coming from Python (as many Go developers do). After debugging, reviewing, and writing at least 3 different local implementations of a set, I can't wait for generics so that it can be written once and then never looked at again.
I mean that people make their own per-file or per-package set implementation for their service. There's no point putting it in a common utility package even within the same company, because it's specific to the type of what they're storing.
`map[T]struct{}` is only a type, it's not an implementation. You still need a handful of methods, that might be named inconsistently in each implementation by different developers. I will be happy when I never have to think about this again
> I'm slightly surprised you found three different set implementations - `map[T]struct{}` is the idiomatic one i see everywhere.
Set storage is not really the concern here, it's the set-theoretic operations which make sets useful (generally speaking, there are cases where all you need is the set being a set e.g. deduplication).
So I wouldn't be surprised that GP found several different implementations of union, intersection, difference, symmetric difference, subset, superset, …
> hint that it was being worked on next and will be implemented into Phoenix as a web dashboard in the future but there was no hint of that mentioned this year
Currently there is EEF Observability WG that is working on integrating OpenTelemetry, so it will not be integrated into Phoenix, but will be more general and more cross-language solution for monitoring.
Previously it was talked about that Elixir would create a telemetry library and then Phoenix (and other libraries like Ecto, etc.) would use it.
And the end goal was to have a Phoenix web UI that would come out of the box that you could goto and see a bunch of really useful things about your server's health, the BEAM but more importantly app specific things like DB query times and all of those interesting stats you would want to see. The beauty of it was you would get all of this for free / nearly free in terms of the work you had to do as an app developer.
Did all of that get scratched for OpenTelemetry? Do you happen to know of a timeline when end users could expect to see the benefits of this new standard in Elixir apps?
The official website at https://opentelemetry.io/ doesn't show Elixir as being a supported language.
Erlang `telemetry` is something different from OpenTelemetry.
> Phoenix (and other libraries like Ecto, etc.) would use it
And this is a fact. Both Plug, Phoenix, and Ecto are using Erlang's Telemetry library.
> And the end goal was to have a Phoenix web UI that would come out of the box that you could goto and see a bunch of really useful things about your server's health
This will probably be implemented as an external library in form of OpenTelemetry as I said.
> Did all of that get scratched for OpenTelemetry?
No, OpenTelemetry and Erlang's Telemetry have different goals. Erlang's Telemetry is meant to be lightweight metrics logging library with API for defining exposed metrics. OpenTelemetry is the OTP application that will ingest these metrics and will expose them to the external services like DataDog or Prometheus.
> The official website at https://opentelemetry.io/ doesn't show Elixir as being a supported language.
1. Each package in Nixpkgs repo has assigned maintainer mentioned in source.
2. Nothing prevents you from using your own repo/hosting solution for Nix channel.
3. Writing or overwriting packages in Nix is dumb easy, so I do not see a problem here as well.
I started using Nix exclusively on macOS and I couldn't be happier. The best part IMHO is the fact that I can easily test different packages without permanently changing my system and dealing with clutter left by these.
So in general, this is less of the problem that you think it is, especially as you clone that repo locally, so you do not hit GH/Savannah on each installation.
I have the same experience. Using NixOS, not just NixPkgs, but it shouldn't matter.
Nix takes security very seriously. See e.g. [1]. Plus, a distribution that defines packages declaratively and makes things so reproducible is the ultimate tool to avoid many security issues.
Similarly, ‘guix lint’ has a CVE “checker” that reports CVEs that affect a given package [0]. Since the Guix package name might differ from the “CPE name” (the naming scheme devised by NIST), Guix package definitions can include the CPE name to make sure ‘guix lint’ will look for the right thing. ‘guix lint’ is also able to determine whether a vulnerability is already patched in the Guix package definition.
There’s also work on a ‘guix health’ program in the pipe [1], which is again complicated by this whole CPE story (which Vulnix seems to ignore.)
Last but not least, Guix has “grafts”, a mechanism that allows for fast security update deployment, meaning that rebuilding the world is unnecessary when applying a security update on a package deep down in the dependency graph [2, 3].
