When I build socrates using `sudo nixos-rebuild [...] switch`, my
`nixos-config` (i.e. <briefcase/nixos/socrates/default.nix>) is a simple Nix
anonymous function. Typically readTree populates my pkgs, briefcase, depot
function parameters with <nixpkgs>, <briefcase>, <depot>, but `nixos-rebuild` is
unaware of `readTree`.
For now I'm manually importing these dependencies, and I'm leaving a TODO to
reconsider switching to the `{ pkgs, briefcase, ... }` style when I better
understand NixOS.
When I first created the monorepo, I borrowed @tazjin's monorepo's. I adapted
his depot/default.nix, replacing some of his paths with my paths. This worked
for me until recently.
I attemped to include <briefcase/monzo_ynab/job> as a systemd unit for my NixOS
machine, socrates. NixOS failed to build my changes, and I didn't fully
understand my default.nix since I borrowed most of it from @tazjin. I spent the
past week looking at the `fix` function. I realized that I didn't fully
understand how fixed-point recursion worked. This sent me down a rabbit hole
terminating with me studying the Y and Z combinators.
Ironically, after understanding the `fix` function, I realized that I didn't
need to use it where I was consuming it. I ended up pruning most of my
configuration, which resulted in this commit.
Yours truly,
lambda f: (lambda x: f(x(x)))(lambda x: f(x(x)))
Write a function that returns the highest product of three integers within a
list of integers. This solution uses a greedy algorithm that solves for the
answer in linear time. The space complexity is constant.
Write a function that returns the maximum profit that a trader could have made
in a day. I solved this using a greedy algorithm which constantly sets the
maximum profit by tracking the lowest price we've encountered.
Months ago when I was revisiting Nix, I decided to nixify my fish
configuration. This was a useful learning exercise. I've had two config.fish
files floating around this repository ever since then. I sometimes update one
and other times I update the other. I'm consolidating these files into one, so I
that this is no longer as issue.
Maybe this is my recency bias writing, but "Being Popular" may be one of my
favorite Paul Graham essays that I've read.
"Being Popular" outlines Paul Graham's ideas about what an ideal programming
language would look like. This essay took me 1-2 hours to read, but it was worth
the time.
Here are some quotes that I enjoyed (not sorted in any meaningful order):
"A friend of mine rarely does anything the first time someone asks him. He knows
that people sometimes ask for things that they turn out not to want. To avoid
wasting his time, he waits till the third or fourth time he's asked to do
something; by then, whoever's asking him may be fairly annoyed, but at least
they probably really do want whatever they're asking for."
"In this particular case there is a way to finesse our way out of the
problem. If we treat data structures as if they were functions on indexes, we
could write (a x y) instead, which is even shorter than the Perl form. Similar
tricks may shorten other types of expressions."
"The latest hot language, Python, is a watered-down Lisp with infix syntax and
no macros."
"Hackers would think a lot more highly of Lisp if Common Lisp had powerful
string libraries and good OS support."
"I think language designers would do better to consider their target user to be
a genius who will need to do things they never anticipated, rather than a
bumbler who needs to be protected from himself."
Some take-aways:
- Let's refer to Python as "Diet Lisp" from now until the end of time.
- Fight to keep your user-base small for as long as you can. Only fools want
large user bases.
- Rich Hickey definitely read this article; he took some ideas with him; he left
some ideas behind.
- Focus language design efforts around defining rich standard libraries,
especially for string manipulation.
- Worry little about supporting backwards compatibility; design a language that
can and is often rewritten.
- Shift the burden of optimizing code performance to the user by designing a
powerful runtime profiler that is tightly integrated into the language
runtime.
- Minimize the costs users face when experimenting: ensure that your language is
interactive; ensure users can create REPLs quickly.
- Support OS-level libraries (think about Go).
- Maximize introspection and hackability.
What a useful read!
I'd like to be able to call...
`nix-build -E '(import <briefcase> {}).nixos.socrates'`
...as part of my efforts to wane my dependence off of `nixos-rebuild`.
I'm not sure if this commit breaks everything in my monorepo. I think it
will.
Why am I doing this? Perhaps it's a bad idea. I don't fully understand how
readTree works. My ignorance is costing me hours of time spent debugging. In an
effort to better understand readTree, I'm removing the default values for my Nix
expression parameters, which I believe have preventing errors from surfacing.
The implementation for provisioning ACME certificates has changed in
nixos-unstable[0] and now requires a few extra options to be set.
[0]: https://github.com/NixOS/nixpkgs/pull/77578
* exwm-input.el (exwm-input--noop): New placeholder command.
(exwm-input--on-pre-command, exwm-input--on-post-command): Ignore this
command.
(exwm-input--on-KeyPress-line-mode): Set `last-command' to make
winner-undo start over from the newest config; run
`post-command-hook' to make winner-mode save configs; run
`pre-command-hook' in case required by some other package.
--
09c1e7877210fe85c43631538303af801c233e89 by Gennadiy Rozental <rogeeff@google.com>:
Change CordRep::length to size_t to be compatible with ChunkIterator.
PiperOrigin-RevId: 297901255
--
226d5e79fb4e20fb09d75f034624d5be770f4ece by Derek Mauro <dmauro@google.com>:
Makes absl::string_view::substr constexpr for std::string_view compatibility
Fixes#627
PiperOrigin-RevId: 297872778
--
851aa24a22d0ba5552098bf7e5735c95e4a8d4f7 by Abseil Team <absl-team@google.com>:
Reformat one line.
PiperOrigin-RevId: 297839574
--
4f449c462583797455375fa6f1365a6b2cfa7e0a by Benjamin Barenblat <bbaren@google.com>:
Internal change
PiperOrigin-RevId: 297677173
--
2d41a250e9a8f272946bc3262463e4025d88fba3 by Abseil Team <absl-team@google.com>:
Internal change
PiperOrigin-RevId: 297537076
--
6e7fbe1e90999a58556d41955bef44033c61876c by Gennadiy Rozental <rogeeff@google.com>:
Internal change
PiperOrigin-RevId: 297376994
--
5acf79338191b31cec158b06cd96ca8dfa3e81fe by Derek Mauro <dmauro@google.com>:
Add a debug-mode bounds-check on absl::Span::operator[].
PiperOrigin-RevId: 297355826
--
1c540d06a56c7e92bb07b90f16b4e00b014ef18f by CJ Johnson <johnsoncj@google.com>:
Adding new LTS to the list
PiperOrigin-RevId: 297235265
--
696ce48bea6927436ff89f59b887e5869b1b0f38 by Derek Mauro <dmauro@google.com>:
Fix build on FreeBSD/powerpc (implement UnscaledCycleClock)
Merges/Fixes GitHub #616
PiperOrigin-RevId: 297188640
GitOrigin-RevId: 09c1e7877210fe85c43631538303af801c233e89
Change-Id: I5d97b16bb6378792d2fcf7d29080cca18aa7729a
Adds the proto definitions required for the Stackdriver Logging API.
This compiles, but I'm unsure whether it's actually correct because
there seems to be a lot of copy & paste in the build setup.
Updates the build process for googleapis in C++ to read the proto
sources from the GOOGLEAPIS_DIR environment variable (injected by Nix)
instead of attempting to download them at build time.
--
20405fc394419d434d3ea09b2e62e4edcb282421 by Christian Blichmann <cblichmann@google.com>:
Include `status` subdirectory in main `CMakeLists.txt`
PiperOrigin-RevId: 297125966
--
101087af9689612bdda679ee0869e5cde4472244 by Matt Kulukundis <kfm@google.com>:
Fix typo
PiperOrigin-RevId: 296991360
--
55ff5bc6970d46214c0459d3a7a23973c7dc69b9 by Andy Getzendanner <durandal@google.com>:
Extract logging's ErrnoSaver to absl::base_internal and use it in a couple other places.
PiperOrigin-RevId: 296969168
--
b7cd7550297d53766576f751436617200c65831b by Abseil Team <absl-team@google.com>:
Internal change
PiperOrigin-RevId: 296951474
--
8c04c73fc53f9a09c3e2400812b931157f35fe07 by Andy Soffer <asoffer@google.com>:
Auto-generate list of files in the DLL, and add new build targets to the DLL.
PiperOrigin-RevId: 296932061
--
2f77829e196094f1addefd8ac2ac9e398c5b6100 by Andy Soffer <asoffer@google.com>:
Fix bug introduced by DLL where we couldn't build shared libraries on
non-windows platforms.
Fixes#623
PiperOrigin-RevId: 296919347
--
b768163dbbff0c561b9dff0218a699e5e4fd33f3 by Abseil Team <absl-team@google.com>:
typo: microprosessor
PiperOrigin-RevId: 296904933
--
b185da0dac44c91855373f0723df9242cbfb3db3 by Matthew Brown <matthewbr@google.com>:
Internal cleanup
PiperOrigin-RevId: 296509711
GitOrigin-RevId: 20405fc394419d434d3ea09b2e62e4edcb282421
Change-Id: I55c8eba6f353ceb337455ae144ab743ea21edbef
This adds very basic capability[0] and message tag[1] support to rcirc
which is used to implement support for the IRCv3 server-time[2] spec.
During connection setup, the server is asked to list its capabilities
and the `server-time` capability is then blindly requested from
it (the CAP handler code does not check whether server-time is
actually part of the listed capabilities). rcirc does not need to know
whether this negotiation succeeded, because server time tags will
either be sent or not.
By default rcirc prints all timestamps at current-time. A new variable
`rcirc-last-message-time` has been added which, if set, overrides this
timestamp. It is set by the message handler after parsing IRCv3 tags.
Thanks to William Cummings for nudging me in the direction of his post
about adding ZNC playback support to rcirc[4], from which some parts
of this code were taken.
This has been tested with IRCCloud's bouncers.
[0]: https://ircv3.net/specs/core/capability-negotiation
[1]: https://ircv3.net/specs/extensions/message-tags
[2]: https://ircv3.net/specs/extensions/server-time-3.2.html
At the moment, I don't think nixos-rebuild is reading $NIX_PATH, which
appropriately sets the paths for depot and briefcase. I'm going to explicitly
expose these values in the rebuild script for now.
After I considered the security implications of calling
`systemctl --user cat monzo-token-server`, I realized that monzo-token-server
should be a root service instead of a user service.
This service unit now also explicitly depends on briefcase.monzo_ynab.tokens,
which is a big improvement.
Paying off some tech debt. Instead of relying ./kv.json existing, which is
relative to the directory from which I start a program, I'm preferring that a
consumer explicitly provides this path.
"oneshot", according to `man systemd.service`, "will consider the unit up after
the main process exits". Since I designed token-server to run continuously, it
will not intentionally exit; therefore, systemd awaits its exit, which never
comes. "simple", on the other hand, does what I want.
Here is my first attempt to manage secrets when I deploy onto a NixOS machine.
Background: When I develop, I use direnv, which reads an .envrc file in which I
define my secrets. My secrets are read from `pass` using a pattern like this...
```shell
secret_value="$(pass show path/to/secret)"
```
...Thus far, I've found this pattern convenient. `pass show` invokes GPG, which
asks me for a password to authenticate. This means that when I cd into a
directory with an .envrc file using this pattern, I may be prompted by GPG for a
password. When I'm not, it's because gpg-agent is still caching my
password. This works for development, but I currently do not know how to use
direnv for deployments.
Here is what I'm using until I find a more convenient solution:
- Store the secrets in /etc/secrets on socrates. Ensure that the /etc/secrets
directory and its contents are only readable by root.
- Use systemd's Environment and NixOS's builtins.readFile to read the files in
/etc/secrets when I can `sudo nixos-rebuild`.
Ideally I could call a function like `builtins.readFromPasswordStore` within
configuration.nix. This would allow me to skip the step where I run...
```shell
> ssh socrates
> pass show finance/monzo/client-id | sudo tee /etc/secrets/monzo-client-id
> pass show finance/monzo/client-secret | sudo tee /etc/secrets/monzo-client-secret
> # etc
```
...I don't know how to manage secrets using NixOS, but at least this is one
answer.
TL;DR:
- Move /etc/nixos/configuration.nix -> //nixos/configuration.nix
- Move /etc/nixos/hardware-configuration.nix -> //nixos/harware.nix
- Document installer.nix
- Create rebuild.nix wrapper around `sudo nixos-rebuild switch`
Previously I sketched ideas for the configuration.nix for socrates -- also known
as flattop -- the inexpensive Acer laptop residing in my flat and stored that
configuration.nix file in briefcase. Now, however, I have successfully installed
NixOS onto socrates. By default NixOS saves the configuration.nix and
hardware-configuration.nix files to /etc/nixos/. I'm moving both of these files
into briefcase.
Because the command `nixos-rebuild` looks for the NixOS configuration
file in /etc/nixos, I wrote rebuild.nix, which creates a program to
call `nixos-rebuild` with the new location of my configuration.nix.
