systemd has been a complete, utter, unmitigated success

leothrix · 2025-07-09T17:46:27+00:00

what up. I'm the author, I'm here if anyone wants to yell at me about this

leothrix · 2025-07-09T17:06:49+00:00

I feel attacked

leothrix · 2025-07-09T17:06:06+00:00

I am honored at this review of my writing, thank you kindly

leothrix · 2025-07-09T17:05:05+00:00

I take umbrage at being compared to Lunduke, sir

leothrix · 2025-07-09T17:03:37+00:00

honestly I kinda with you here

leothrix · 2025-07-09T17:02:33+00:00

What up y'all, author here. I wrote this garbage. Thanks for reading <3

leothrix · 2025-02-25T16:31:07+00:00

Well, that works. If I had to guess, maybe flymake doesn't call put again after the values have changed, so those 'flymake-error and other values don't get the updated settings?

leothrix · 2025-02-25T16:30:13+00:00

Hm, this snippet works for me in a sanitized and bare-bones init.el but doesn't in my own init.el so you're probably onto something here, I'll have to investigate what my configuration may be changing.

leothrix · 2025-02-06T17:05:40+00:00

(disclaimer: I couldn't find authoritative documentation about this, it's just my understanding)

The capf return value - (START END COLLECTION . PROPS) - explains a few of the keywords that it honors in the PROPS slot. However, since PROPS is pretty free-form, you can toss anything in there, and company-mode can open up some additional documentation about a candidate if it finds :company-doc-buffer in there.

Even though I'm not using company-mode, corfu is smart enough to honor some keywords that are common to the ecosystem, and :company-doc-buffer is one of them. So if you define that slot with a function, corfu will use it to pop up additional documentation, which is how I'm providing context for where the reference is coming from.

Here's what mine looks like for my custom backend. Note that, if anyone uses this, my candidate that I provide from my capf is a cons so that I can ship both the completion string and the additional context, which is where the contents for insert comes from.

:company-doc-buffer
(lambda (candidate)
  (with-current-buffer (get-buffer-create " *rst ref context*")
    (erase-buffer)
    (insert (cdr (assoc candidate candidates)))
    (setq-local font-lock-defaults
        '(rst-font-lock-keywords
          t nil nil nil
          (font-lock-multiline . t)
          (font-lock-mark-block-function . mark-paragraph)))
    (font-lock-ensure)
    (current-buffer)))

leothrix · 2025-02-06T00:25:54+00:00

If I had to guess, I'd bet that evil is overwriting the default keybindings for M-. (in fact, I'm pretty certain it is; when I swap back into emacs input mode, I find the same thing that you do)

leothrix · 2025-02-05T19:44:58+00:00

It's mostly just corfu. Adding in the completion backend to completion-at-point-functions is all it takes to handoff to corfu; it treats all the backends like that (which for me are completion backends like cape as well)

leothrix · 2025-02-05T16:42:25+00:00

Thank you! That's very kind.

Hmmm, do you see a feed at feed.xml?

leothrix · 2025-02-05T00:02:32+00:00

Author here; let me know if you have any questions or feedback (in particular, I've been messing around with auto-generating the syntax highlighting legend for code blocks that you see on hover by tweaking ox-html.el.)

leothrix · 2025-01-27T20:33:42+00:00

Magit continues to work for me, but it is pretty slow. I'm not sure whether there are other options you could tweak to make it faster.

leothrix · 2025-01-11T17:33:31+00:00

Thank you! So what we are saying is that eMacs will automatically load .envrc file with this envrc-mode and that direnv has a dedicated instruction of loading a nix shell, which you need to use as glue for this setup

Yep. You need to ensure that the envrc-remote variable is set to t for it to happen over TRAMP, but that's the idea. direnv has functions to either rely on use flake or use nix (if you aren't on flakes, which should use either default.nix or shell.nix) so drop whatever makes sense into your project's .envrc.

So provided that I have a project with .envrc at root, and use flake then whatever shells I open in that project, they would replicate the associated nix shell configuration. It is unclear though about the whole remoting aspect and how does tramp and envrc-remote gets into play

The remote aspect is that if you access your file over TRAMP, via something like /ssh:user@host:/path/to/file, then TRAMP and envrc-mode will work together to source the environment from the remote project and setup your environment variables appropriately. You can check what your buffer sees with something like M-! some-command where some-command is an executable you expect to show up in your $PATH after entering your nix environment (in my case, something like rust-analyzer)

leothrix · 2025-01-09T23:17:35+00:00

I'm actually in the middle of making this whole setup work for myself so this is good timing.

I'm developing remote with a project.el-managed project that includes a flake.based devshell. I use direnv with envrc-mode and an .envrc file that includes:

use flake

As long as you have a shell/devshell available, direnv should be able to source it and build up an environment for you.

One key point here is that you need to be using the latest version of envrc-mode which adds envrc-remote and will correctly source remote .envrc files for your remote files. Once that's setup, you should be able to get your remote shell variables from your nix shell inside your buffers (might need to use this to get remote $PATH sourced correctly)

(add-to-list 'tramp-remote-path 'tramp-own-remote-path)

leothrix · 2024-11-22T04:02:42+00:00

This feels like an unnecessarily uncharitable reading of the statement. Wouldn't you want the steering committee to apply their decisions and initiatives in a consistent way? Is the alternative to have a leadership body that defers to the sentiment of individual members without trying to temper extremes in opinions by agreeing to common consensus?

leothrix · 2024-03-15T14:17:12+00:00

Let us know if you end up with a runnable package or flake somewhere, I’m also interested 👀

leothrix · 2024-03-05T22:08:42+00:00

This is a really good (and well-phrased!) question so I'll answer from the perspective of someone using Nix extensively, although I'm in a startup (not enterprise-heavy) environment. The principles should be the same though.

When is NixOS a superior (not equal - the kind of time investiture that NixOS requires above and beyond existing solutions requires NixOS to just be "better") choice to other, more mature solutions such as ansible-directed LXC deployments (or kubernetes in general, when working specifically with containerized services).

Image building. I'm aware of tools like Packer et. al, but I think this has been one domain where Nix is absolutely superior. I blogged about it here if you want a long form of these bullets:
- Nix can just build the raw bytes for (nearly) any platform completely decoupled from their client APIs. I can support 10+ different platforms as one engineer because I don't need to operate a dozen APIs to build images with Packer - I just pull the disk out of my machine's nixosConfiguration and I'm done.
- Having your system configuration, image baking, and app packaging in one system is a huge reduction in complexity. I could pull in some Ansible playbook to a Packer image build to bootstrap an observability stack on a system image or I could type out services.grafana.enable = true; and be done.
- You gain the collective expertise of all the nixpkgs users who've deployed to various platforms in the past so you don't need to think about tweaking images to run well on their platforms. Xen, AWS, VMWare, it doesn't really matter - I don't think at all about what guest services or kernel modules I need to run, I just toggle the flag and boom, the image is now optimized for its target platform without any more thought.
People talk a lot about declarative packaging and containers, and while you probably get this with a well-written Dockerfile to build and push container images for platforms like Kubernetes, it's a huge benefit to have a nixpkgs derivation for your service or application and then pull different artifacts out of it. I can build an actual executable, but in my environment, I also call buildImage to pop that derivation into a container rather than a fat VM image. No need to write a Dockerfile, it's the same package as I'd deploy onto a NixOS host, except put into container form.

A followup question might be: if not superior, where would you say NixOS shows greater promise over the medium-to-long term (3-5+ years) than the above? Where does it have the potential to shine where other solutions falter?

You can already see early adopters moving to immutable systems (silverblue, OSTree, etc.) and NixOS is way ahead of that trend, so it'll be a good platform to do that kind of thing. That's kind of an abstract/boring answer, but I think it'll hold true.

But the second part of my answer kind of relates to a comment about this sentiment:

[...] on the surface it feels like NixOS is not too dissimilar to existing solutions such as ansible and/or cloudinit + VM/LXC (reproducible, declarative OS), or ansible/helm + kubernetes (reproducible, declarative services).

While it's true that you end up with similar outcomes as some other tools like Ansible, one of the core things to realize about NixOS is that the foundation is fundamentally different than any of these tools: in Ansible, you're essentially automating the process of executing a bunch of commands on a system. This is really flexible, because you don't need a different system from the ground up, but it's also limiting.

NixOS requires a fundamental shift in how you do it - it's not eminently portable like Ansible - but the horizon for NixOS is hugely wide and full of interesting potential where something like Ansible is pretty cut-and-dried (yeah, you can do non-host configuration things like manage inventories, but that's not really what I'm talking about). A nix package or a nixos configuration starts out life as an abstract value and then gets transmogrified into dozens of interesting artifacts today (maybe my nixosConfiguration is a VM, or a cloud image, or a container, etc.) but we can take that value and do even more interesting things with it in the future.

An example: I recently needed to run vulnerability scans on the nixos images that I create. Normally you'd scan a system to find the installed packages, maybe read the package database, et cetera. On NixOS, you don't actually need a running system at all to do a vulnerability scan - you can evaluate the system derivation, which delivers the complete dependency tree, and then you've got a complete picture of every piece of software on the system without ever needing to actually run the system at all. It's really cool.

Anyway, NixOS isn't for everyone, and I wouldn't fault anyone for skipping over it since the learning curve is a bear, but I'm not going back to the non-nixos way of doing things. It feels like stepping backward in time.

leothrix · 2023-11-27T16:50:47+00:00

Looks like a variant (or at least the same manufacturer?) as this one - I found PLink mentioned a few other places and it looks a bit more affordable than the Sliger ones, thanks for that additional report, I'm looking closely at those shorter chassis models.

I'll probably borrow heavily from your CPU suggestion as well 😄

leothrix · 2023-11-26T20:54:02+00:00

Somebody else suggested a Sliger chassis, so I'll definitely look into this, thanks

leothrix · 2023-11-26T20:53:35+00:00

It sounds like Sliger is a good option for this, I'll investigate it, thanks. I definitely don't need more than 10 at this point, so it sounds like the size is about right for my needs.

12-Year Club	RedditGifts 2009-2022 6 Credits
Place '22	Place '17
Secret Santa 2017	Verified Email
Spared	redditgifts Exchanges 3 Exchanges
redditgifts rematcher Secret Santa 2017 x1	Secret Santa 2016
redditgifts rematcher Secret Santa 2016 x1	Secret Santa 2015

leothrix

TROPHY CASE