101 Matching Annotations
  1. Jun 2021
  2. May 2021
    1. This post was originally published on my blog in french and on the Litmus forums in June 2015. It was updated with information about support in the new Outlook Web App in January 2016.
    1. The command nix-shell will build the dependencies of the specified derivation, but not the derivation itself. It will then start an interactive shell in which all environment variables defined by the derivation path have been set to their corresponding values, and the script $stdenv/setup has been sourced. This is useful for reproducing the environment of a derivation for development.

      QUESTION: What exactly does nix-shell execute from the Nix expression (i.e., shell.nix, default.nix, etc.)?

      ANSWER: Based on my current understanding, the answer is everything. It calls $stdenv/setup (see annotation below) to set up the most basic environment variables (TODO: expand on this), and "injects" the most common tools (e.g., gcc, sed) into it.

      It also defines the phases (TODO: verify this) and builder functions, such as genericBuilder. For example, the default builder is just two lines:

      source $stdenv/setup
      genericBuild
      

      TODO: pkgs/stdenv/generic/builder.sh is a mystery though.

      QUESTION: Once dropping into nix-shell, how do I know what phases to execute by looking at a default.nix? (E.g., [..]freeswitch/default.nix)

      ANSWER: As far as I can tell, one can override the phases in their Nix build expression (to build the derivation, see at the bottom), but they won't get executed as only the $stdenv/setup (see above) will get sourced, and no builders are called that, in return, invoke the phases (again, see above).

      So if one is using nix-shell

      • to create/hack on a package, the person has to manually invoke the builder or phases (TODO: still fuzzy on this subject)

      • to set up an environment, then one doesn't even have to worry about builders/phases because we just use nix-shell to clear the environment and to inject tools that we need for a given task

      QUESTION: When dropping into nix-shell, is this Nix expression (i.e., freeswitch/default.nix) executed? Or just parts of it?

      ANSWER: As stated above, all of the input Nix expression is evaluated, but no builders and build phases are called; although, nothing prevents one to override the phases, in case they are creating/hacking on a package.

      QUESTION:

      The command nix-shell will build the dependencies of the specified derivation, but not the derivation itself.

      What is the "derivation" here exactly? I know that it is a build expression, but does that mean the default.nix (or other Nix expression) nix-shell is invoked with?

      <sup>This statement also seems like a contradiction with how `nix-shell` works (i.e., if one issues `nix-shell -p curl`, then `curl` will be available in that sub-shell), but `-p` acts like a shortcut to as if `curl` had been listed in `buildInputs` so this is not the case.</sup>

      ANSWER: I have the feeling my confusion comes from the fact that the term "derivation" is used ambiguously in the manuals, sometimes to mean multiple things (see list below).

      TODO: Substantiate this claim, and make sure that it not coming from my misunderstanding certain topics.

      • Nix build expression (such as default.nix) whose output is going to become the store derivation itself (see last item at the bottom about the Nix manual's glossary definition)

      • store derivation.

      Had multiple cracks at unambiguously define what a derivation is, and here's a list of these:

      QUESTION: What is the difference between nix-shell -p and nix-shell invoked with a Nix expression of mkShell (or other that achieves the similar effect)?

      QUESTION: nix-shell does not create a sub-shell, so what does it do? (clarification: so nix-shell indeed does it; I confused it with nix shell)

  3. Apr 2021
    1. “Digital technology allows us to be far more adventurous in the ways we read and view and live in our texts,” she said. “Why aren’t we doing more to explore that?”

      Some of the future of the book may be taking new technologies and looking back at books.

      I wonder if the technology that was employed here could be productized and turned into an app or platform to allow this sort of visual display for more (all?) books?

  4. Mar 2021
    1. This is not a fork. This is a repository of scripts to automatically build Microsoft's vscode repository into freely-licensed binaries with a community-driven default configuration.

      almost without a doubt, inspired by: chromium vs. chrome

    1. this only applies to end products which are actually deployed. For my modules, I try to keep dependency version ranges at defaults, and recommend others do the same. All this pinning and packing is really the responsibility of the last user in the chain, and from experience, you will make their life significantly more difficult if you pin your own module dependencies.
  5. Feb 2021
    1. A Nix expression describes everything that goes into a package build action (a “derivation”)

      Come up with an ultimate definition for what a "derivation" is.

      So round up all the places where it is mentioned across Nix* manuals, and check out these:


      From Nix Pills section 6.1. The derivation function (see annotation):

      A derivation from a Nix language view point is simply a set, with some attributes. Therefore you can pass the derivation around with variables like anything else.

      So there is clearly an ambiguity between what derivations are perceived to be and what is stated in the Eelco Dolstra's PhD thesis. Or maybe I'm having issues with reading comprehension again...

    2. For each output declared in outputs, the corresponding environment variable is set to point to the intended path in the Nix store for that output. Each output path is a concatenation of the cryptographic hash of all build inputs, the name attribute and the output name. (The output name is omitted if it’s out.)

      QUESTION: So when I see $out in a builder script, it refers to the default output path because the output attribute in the Nix expression has never been explicitly set, right?

    3. A derivation causes that derivation to be built prior to the present derivation; its default output path is put in the environment variable.

      That is, if an input attribute is a reference to a derivation in the Nix store, then

      1. that derivation is built first (after a binary substitute is not found, I presume), and
      2. the path to the built package (for a better word) is handed to the shell build script.
    4. derivationA description of a build action. The result of a derivation is a store object. Derivations are typically specified in Nix expressions using the derivation primitive. These are translated into low-level store derivations (implicitly by nix-env and nix-build, or explicitly by nix-instantiate).

      Organically related to the annotation regarding my nix-shell confusion.

      The dissection of this definition to show why I find it lacking:

      A description of a build action.

      The first (couple) time(s) I read the manuals, this description popped up in many places, and I identified it with Nix expression every time, thinking that a derivation is a synonym for Nix expression.

      Maybe it is, because it clearly tries to disambiguate between store derivations and derivation in the last sentence.

      The result of a derivation is a store object.

      Is this store object the same as a store derivation?

      Derivations are typically specified in Nix expressions using the `derivation primitive. These are translated into low-level store derivations (implicitly by nix-env and nix-build, or explicitly by nix-instantiate).

      QUESTION: So, the part of the Nix build expression (such as default.nix) where the derivation primitive is called (explicitly or implicitly, as in mkDerivation) is the derivation, that will be ultimately be translated into store derivations?

      ANSWER: Start at section 15.4 Derivation.


      QUESTION: Also, why is typically used here? Can one define derivations outside of Nix expressions?

      ANSWER(?): One could I guess, because store derivations are ATerms (see annotation at the top), and the Nix expression language is just a tool to translate parameterized build actions into concrete terms to build a software package. The store derivations could be achieved using different means; e.g., the way Guix uses Guile scheme to get the same result))


      I believe, that originally, derivation was simply a synonym to store derivation. Maybe it still is, and I'm just having difficulties with reading comprehension but I think the following would be less misleading (to me and apart from re-writing the very first sentence):

      Derivations are typically the result of Nix expressions calling the derivation primitive explicitly, or implicitly usingmkDerivation`. These are translated into low-level store derivations (implicitly by nix-env and nix-build, or explicitly by nix-instantiate).

    5. $stdenv/setup

      QUESTION: Does this refer to pkgs/stdenv/generic/setup.sh? According to 6.5 Phases in the Nixpkgs manual?

      ANSWER: I'm pretty sure it does. It sets up the environment (not sure how yet; I see the env vars, but not the basic commands - sed, awk, etc. - that are listed below) and defines a bunch of functions (such as genericBuilder) but it doesn't call these functions!

    6. The function mkDerivation in the Nixpkgs standard environment is a wrapper around derivation that adds a default value for system and always uses Bash as the builder, to which the supplied builder is passed as a command-line argument. See the Nixpkgs manual for details.

      "Documented" in the Nixpkgs manual under 6.1 Using stdenv.

      Used the double-quotes above because I don't consider it well documted. Will give it a try too; worst case scenario is that I'll fail as well.

    7. C.12. Release 1.6 (2013-09-10)In addition to the usual bug fixes, this release has several new features:The command nix-build --run-env has been renamed to nix-shell.
    8. See annotations with the build-phases tag.


      Why are the build phases not enumerated in the Nix manual? If the instructions on how to create a derivation (and thus, a package) then why not go all in instead of spreading out information in different manuals, making the subject harder to grasp?...

      (By the way, it is documented in the Nixpkgs manual under 6.5 Phases; not sure why it is not called build phases when every page refers to them like that.)

    9. Chapter 14. A Simple Nix Expression

      This such a stupid move to go through a derivation example before introducing the language.

    10. Add the package to the file pkgs/top-level/all-packages.nix. The Nix expression written in the first step is a function; it requires other packages in order to build it. In this step you put it all together, i.e., you call the function with the right arguments to build the actual package.

      In addition to this rant, step 3. should be more generic, instead of tying it to Nixpkgs; at least, either show how to build your own Nix expression repo, or don't add this step, but it is not at all necessary to write a derivation. There is a Nixpkgs manual for a reason.

    11. $ nix-env -i firefox --substituters ssh://alice@avalon This works similar to the binary cache substituter that Nix usually uses, only using SSH instead of HTTP

      So a substitute is a built binary for a given derivation, and a substituter is a server (or binary cache) that serves pre-built binaries, right?

      Update: in the next line it says that "it will fall back to using the binary cache substituter", so I guess that answers it.

    12. substitute

      this is another key topic. Also:

      • substitute vs. substituter => this (I think)

      See annotations with the substitute tag

    13. When you ask Nix to install a package, it will first try to get it in pre-compiled form from a binary cache. By default, Nix will use the binary cache https://cache.nixos.org; it contains binaries for most packages in Nixpkgs. Only if no binary is available in the binary cache, Nix will build the package from source. So if nix-env -i subversion results in Nix building stuff from source, then either the package is not built for your platform by the Nixpkgs build servers, or your version of Nixpkgs is too old or too new.

      binary caches tie in with substitutes somehow; get to the bottom of it. See annotations with the substitute tag.

      Maybe this?

    14. closure

      Another gem: who knows what a "closure" is.

      [This highlight] (a couple lines below) implicitly explains it though:

      The command nix-copy-closure copies a Nix store path along with all its dependencies to or from another machine via the SSH protocol. It doesn’t copy store paths that are already present on the target machine.

      or this, also just a couple lines below:

      the closure of a store path (that is, the path and all its dependencies)

    15. the closure of a store path (that is, the path and all its dependencies)
    16. The command nix-copy-closure copies a Nix store path along with all its dependencies to or from another machine via the SSH protocol. It doesn’t copy store paths that are already present on the target machine. For example, the following command copies Firefox with all its dependencies:
    17. subscribes you to a channel that always contains that latest version of the Nix Packages collection.

      That is a misleading statement. The latest version is where the master branch points, isn't it?

      So a channel points to a Nixpkgs commit (on a branch named after the channel) where all packages inside are deemed stable, and all packages are built to have available binary substitutes by a (hydra) build farm.

    18. A Nix channel is just a URL that points to a place that contains a set of Nix expressions and a manifest.
    19. garbage collector roots

      Definitely avoid this, when a term is used but only introduced formally way later. (There is also a reference to "garbage collector roots" almost at the beginning as well.)

    20. $ nix-env --switch-profile /nix/var/nix/profiles/my-profile $ nix-env --switch-profile /nix/var/nix/profiles/default These commands switch to the my-profile and default profile, respectively. If the profile doesn’t exist, it will be created automatically.

      learn more about profiles; creating new profiles was new info

    21. Chapter 10. ProfilesProfiles and user environments are Nix’s mechanism for implementing the ability to allow different users to have different configurations, and to do atomic upgrades and rollbacks.
    22. user environment
    23. In Nix, different users can have different “views” on the set of installed applications. That is, there might be lots of applications present on the system (possibly in many different versions), but users can have a specific selection of those active — where “active” just means that it appears in a directory in the user’s PATH. Such a view on the set of installed applications is called a user environment, which is just a directory tree consisting of symlinks to the files of the active applications.
    24. nix-env -qas

      ... and it takes AGES to complete

    25. 4.3.1. Change the Nix store path prefix

      There is a lot of place in this manual (and probably in the others as well) where the prefix is referred to (usually with italics, such as "prefix/store"), so in the book

      • this should be linked to this section (or the one in the book), and

      • establish a clear and well-communicated notation to convey this

    26. At the same time, it is not possible for one user to inject a Trojan horse into a package that might be used by another user.
    27. Chapter 6. SecurityNix has two basic security models. First, it can be used in “single-user mode”, which is similar to what most other package management tools do: there is a single user (typically root) who performs all package management operations. All other users can then use the installed packages, but they cannot perform package management operations themselves.Alternatively, you can configure Nix in “multi-user mode”. In this model, all users can perform package management operations — for instance, every user can install software without requiring root privileges. Nix ensures that this is secure. For instance, it’s not possible for one user to overwrite a package used by another user with a Trojan horse.

      Would have been nice to link these to the install chapter where single- and multi-user modes were mentioned.

      How would this look in a topic-based documentation? I would think that his chapter would be listed in the pre-requisites, and it could be used to buld different reading paths (or assemblies in DocBook, I believe) such as practical, depth-first (if there are people like me who want to understand everything first), etc.

    28. reentrancy
    29. You can uninstall Nix simply by running: $ rm -rf /nix
    30. $ mkdir /nix $ chown alice /nix

      Traditionally, when a command should be invoked with sudo, it is either included in the example, or the shell indicator is # instead of $.

    31. To explicitly select a single-user installation on your system:

      It should be noted in this section also that since nix 2.1.0, single user install is the default.

    32. nix-shell '<nixpkgs>' -A pan

      What is happening here exactly?

      nix-shell's syntax synopsis always bugged because it looks like this

      SYNOPSIS
      nix-shell [--arg name value] [--argstr name value] [{--attr | -A} attrPath] [--command cmd] [--run cmd] [--exclude regexp] [--pure] [--keep name] {{--packages | -p} packages...  | [path]}
      

      and the canonical example is nix-shell '<nixpkgs>' -A pan; what tripped me up is that path is usually the first in examples, and I thought that the position of arguments are strict. As it turns out, nix-shell -A pan '<nixpkgs> is just as valid.

      Side note<br> Apparently there is no standard for man pages. See 1, 2.

      '<nixpkgs>' path is the one specified in the NIX_PATH environment variable, and -A pan looks up the pan attribute in pkgs/top-level/all-packages.nix in the Nixpkgs repo.

    33. since packages aren’t overwritten, the old versions are still there after an upgrade. This means that you can roll back to the old version:

      Wouldn't hurt to tell folks that this is a convenience layer, and one could also just use the old package from the /nix/store, even though that path would be long and obscure; one could use symlinks of course.

      Or, onc could just use nix-shell -p that specifies a specific version (that's already in the store), but, of course, it's not that simple...

      https://github.com/NixOS/nixpkgs/issues/9682

    1. Your Rails app Gemfile may have a line requiring sass-rails 5.0: gem 'sass-rails', '~> 5.0' # or gem 'sass-rails', '~> 5' These will prevent upgrade to sprockets 4, if you'd like to upgrade to sprockets 4 change to: gem 'sass-rails', '>= 5'
    1. The work put into Trailblazer 2.1 has been tremendous, it could easily have been TRB 3.0, or even TRB III, since Roman version numbering turns out to be quite a fancy thing to do. However, as much as the internals have been improved, as little has changed on the public APIs of Trailblazer, so we decided to go with a minor release.
    1. Specifying a name and a src is the absolute minimum Nix requires.

      Didn't they mean what mkDerivation requires?

      I have been jumping around in this manual, so not sure about what arguments does derivation require.

    2. For convenience, you can also use pname and version attributes and mkDerivation will automatically set name to "${pname}-${version}" by default.

      The error messages are not helpful when one messes up the input attribute set ofmkDerivation (i.e., either name, or pname and version attributes have to be present); see Nixpkgs issue #113520.

    3. 6.1. Using stdenv
    4. fetchpatch works very similarly to fetchurl with the same arguments expected. It expects patch files as a source and and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
    5. 19.3. Submitting security fixes Security fixes are submitted in the same way as other changes and thus the same guidelines apply. If the security fix comes in the form of a patch and a CVE is available, then the name of the patch should be the CVE identifier, so e.g. CVE-2019-13636.patch in the case of a patch that is included in the Nixpkgs tree. If a patch is fetched the name needs to be set as well, e.g.: (fetchpatch { name = "CVE-2019-11068.patch"; url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch"; sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8"; }) If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch. Critical security fixes may by-pass the staging branches and be delivered directly to release branches such as master and release-*.
    6. 18.6. Patches Patches available online should be retrieved using fetchpatch. patches = [ (fetchpatch { name = "fix-check-for-using-shared-freetype-lib.patch"; url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=8f5d285"; sha256 = "1f0k043rng7f0rfl9hhb89qzvvksqmkrikmm38p61yfx51l325xr"; }) ];

      ... and from Chapter 11:

      fetchpatch works very similarly to fetchurl with the same arguments expected. It expects patch files as a source and and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.

      ... and also adding highlight of 19.3. Submitting security fixes

      because these are the only places I've seen fetchpatch mentioned.

      From the wild in freeswitch/default.nix in Nixpkgs:

      stdenv.mkDerivation rec {
        pname = "freeswitch";
        version = "1.10.5";
        src = fetchFromGitHub {
          owner = "signalwire";
          repo = pname;
          rev = "v${version}";
          sha256 = "18dhyb19k28dcm1i8mhqvvgm2phsrmrwyjmfn79glk8pdlalvcha";
        };
      
        patches = [
          # https://github.com/signalwire/freeswitch/pull/812 fix mod_spandsp, mod_gsmopen build, drop when updating from 1.10.5
          (fetchpatch {
            url = "https://github.com/signalwire/freeswitch/commit/51fba83ed3ed2d9753d8e6b13e13001aca50b493.patch";
            sha256 = "0h2bmifsyyasxjka3pczbmqym1chvz91fmb589njrdbwpkjyvqh3";
          })
        ];
        postPatch = ''
          patchShebangs     libs/libvpx/build/make/rtcd.pl
          substituteInPlace libs/libvpx/build/make/configure.sh \
            --replace AS=\''${AS} AS=yasm
      
          # Disable advertisement banners
          for f in src/include/cc.h libs/esl/src/include/cc.h; do
            {
              echo 'const char *cc = "";'
              echo 'const char *cc_s = "";'
            } > $f
          done
        '';
      
    7. 6.5. Phases

      Not sure why this isn't called build phases... See also.

    1. undermine the integrity of the Version of Record, which is the foundation of the scientific record, and its associated codified mechanisms for corrections, retractions and data disclosure. 

      This misrepresents the situation. Authors accepted manuscripts (AAM) have been shared on institutional and subject repositories for around two decades, with greater prevalence in the last decade. Despite this the version of record (VoR) is still valued and preserves the integrity of the scholarly record. The integrity of the VoR continues to be maintained by the publisher and where well-run repository management are made aware, corrections can be reflected in a repository. The solution to this problem is the publisher taking their responsibility to preserving the integrity of the scholarly record seriously and notifying repositories, not asserting that authors should not exercise their right to apply a prior license to their AAM.

    2. the Rights Retention Strategy is not financially sustainable

      So far as I know this is not tested or based on any evidence. If the publishers think an open accepted manuscript would undermine the version of record, it doesn't demonstrate much confidence in their added value to me.

  6. Jan 2021
  7. Dec 2020
    1. Sucrase is an alternative to Babel that allows super-fast development builds. Instead of compiling a large range of JS features to be able to work in Internet Explorer, Sucrase assumes that you're developing with a recent browser or recent Node.js version, so it focuses on compiling non-standard language extensions: JSX, TypeScript, and Flow.
    2. Super-fast alternative to Babel for when you can target modern JS runtimes
    1. Everything Lives in GitWith a Jamstack project, anyone should be able to do a git clone, install any needed dependencies with a standard procedure (like npm install), and be ready to run the full project locally. No databases to clone, no complex installs. This reduces contributor friction, and also simplifies staging and testing workflows.
  8. Nov 2020
    1. Microbundle also outputs a modern bundle specially designed to work in all modern browsers. This bundle preserves most modern JS features when compiling your code, but ensures the result runs in 90% of web browsers without needing to be transpiled. Specifically, it uses preset-modules to target the set of browsers that support <script type="module"> - that allows syntax like async/await, tagged templates, arrow functions, destructured and rest parameters, etc. The result is generally smaller and faster to execute than the esm bundle
  9. Oct 2020
  10. Sep 2020
  11. Aug 2020
  12. Jul 2020
    1. RDFa is intended to solve the problem of marking up machine-readable data in HTML documents. RDFa provides a set of HTML attributes to augment visual data with machine-readable hints. Using RDFa, authors may turn their existing human-visible text and links into machine-readable data without repeating content.
    1. Every AMP document needs to have a link referencing the "canonical" version of that document. We'll learn more about what canonical pages are and different approaches to canonical linking in the Making your page discoverable step of this tutorial.
    1. Canonical linking in regular HTML pages is a common technique for declaring which page should be considered the preferred page when multiple pages include the same content.
  13. May 2020
    1. In the examples below, we are using Docker images tags to specify a specific version, such as docker:19.03.8. If tags like docker:stable are used, you have no control over what version is going to be used and this can lead to unpredictable behavior, especially when new versions are released.
  14. Apr 2020
  15. Mar 2020
    1. Q. What is up with the weird version scheme in Rubinius? A. Rubinius uses a simple epoch.sequence version scheme. For any sequence number N, N+1 will only add new capabilities, or remove something that has been listed as deprecated in <= N.
    2. Q. Why does Rubinius report the Ruby version as 10.0? A. Rubinius is a time machine. When you use it, you travel into the future. Even this README is in the future.
  16. Dec 2019
  17. Jul 2019
    1. Flutter 1.7A leading cross-platform framework Flutter SDK releases its new version 1.7. The new version has come with some in testing updates that aids developers to build an interactive mobile application.

      A new Flutter update has been announced. Flutter SDK has released Flutter 1.7 with upgraded services. Flutter’s new version supports many new features.

  18. May 2019
    1. But Jonah rose up to flee to Tarshish from the presence of the Lord. So he went down to Joppa, found a ship which was going to Tarshish, paid the fare and went down into it to go with them to Tarshish from the presence of the Lord.

      This is more than just a travel log. Here Jonah is saying no to God. He is refusing God’s plan for him. He is actually rejecting a direct request from the creator because of his own interests. Maybe he is afraid to prophesy repentance because his life could be at risk. There may be smooth sailing at first, but the wrath of God eventually catches up with him.

  19. Aug 2018
    1. Legislative staff members had finished rewriting AB 375, and a deal seemed imminent. That Friday, as he drank his morning coffee, Mactaggart decided to read the new bill — the fine print — one more time. He noticed a seemingly minor alteration in one section, the kind of thing most people would skip over. Mactaggart realized it would completely gut what remained of the private right of action. Furious, he called Hertzberg and Chau and told them the deal was off. Neither lawmaker could explain who made the change, Mactaggart told me, but Hertzberg scrambled to fix it. “In most negotiations, you are talking to all these different interest groups,” Hertzberg told me recently. “This is a situation where we had to go and reach out to everyone and bring that information to Mr. Mactaggart and ask him what he wanted to do.”

      Here's a case where we ought to consider creating our bills and laws via version control, so we can see exactly who, what, and when things changed along the way. It might mean much less gets done, but there'd be a lot more transparency and accountability.

    1. Contrary to paper notes, computer files do not display the traces or versions that led to their final state.

      This seems weirdly overstated. How do paper notes maintain versions and traces? Electronic documents contain rich sources of meta data for trace analysis, as well as various options to explicitly demonstrate temporal order and change through formatting.

  20. Jun 2018
    1. I think there is a need to develop a system to track the draft of a manuscript from the beginning to the end of the process.

      If you're drafting in WordPress you can set the number of revisions of your posts to infinite so that you can keep (archive) all of your prior drafts. see: https://codex.wordpress.org/Revisions

  21. Sep 2017
    1. a lack of version control over the vast majority of the research literature makes actually ‘adapting’ papers to include post-publication comments is impossible.

      This is also key.