pod cast

The topic isn’t in my interest, but you seem like really likable guys, nice work.

edit: whoops, I misunderstood but still nice work.

I haven’t played with the PEG parser in Facctor yet, hearing this intrigues me a bit, however.

There is already an implicit stack in factor, but because it does duty as being where the parameters live, it might be a little tricky to use in the way that the Tiny C compiler uses it (I haven’t checked the tcc, so I don’t know for sure), if there’s any off-stack state (though factor does have globals and dynamic/lexical variables that could also be used).

I would say the point of shell is composing other programs well, not hacking stuff poorly, that is what python/perl is for :)

That being said, I agree with you, shell has so much potential, but is so shitty for some unknown reason.

For me the whole point of shell scripting is that if it breaks, I can easily decompose the program into parts, and execute each part independently.

For getting things done, I’d rather use any general-purpose dynamically-typed scripting language.

It’s not 100% clear but I’m referring to the original tweet being smug: the person who made the “we men of industry” tweet. I cut off their username to anonymize them.

Any plans for features you want to include? or is it to recreate something as a learning experience?

Oh, ours from vodafone NZ are 16 chars 0-9a-zA-Z

I never had this realization. Now my head has exploded.

What tool do you use to try these combinations? And is it heavily parallelized? To me 4 billion should not take a whole day…

In Luxembourg every (Fritz)box comes with a password written only on the notice (not on the box itself) that is 20 (5*4chars) in hexa. It’s a pain to type at first, but well, it’s seem like a good one.

It says that is a future TODO.

One more vote for pass, i’ve been a happy user for years now. Was missing a proper browser extension for it so I built one: Browserpass. It’s no longer maintained by me due to lack of time, but the community is doing a far better job at maintaining it than I possibly could so that’s all good!

Pass looks pretty neat, but the reason I stick with KeePass(XC) is that Pass leaks metadata in the filenames - so your encryption doesn’t protect you from anyone reading the name of every site you have an account with, which is an often overlooked drawback IMO.

The QR code feature of pass is neat for when you need to login on a phone.

Seems like the android version’s maintainer is giving up. (Nice, 80k lines of code in just one dep…)

The temptation to nih it is growing stronger but I don’t have enough time :(

The idea is you structure your program so it isn’t bouncing between privilege levels. It should not be possible to ever climb back out of a position of limited access. Sometimes this means using something like privilege separation where different processes work together, passing file descriptors, etc.

I use NixOS on everything and completely agree. It’s a massive investment. It was worth it for me, but it shouldn’t have to be a massive investment. Need better tooling and docs.

You basically need to read all the nix pills (https://nixos.org/nixos/nix-pills/), the nix manual, the nixpkgs manual and the nixos manual in a loop gradually filling in what is going on… which takes a long time.

I’ve tried reading all of this but I found it all horribly confusing and frustrating — until I read the original thesis on it, which I still think is (perhaps surprisingly) still the best resource for learning how nix works. It’s still a pretty big investment to read, but imho it’s at the very least a much less frustrating experience than bouncing from docs to docs.

(I wonder if the same is true of the NixOS paper?)

How do you manage secrets in configuration files? Passwords, ssh keys, tls certs and so on. If you put them into a nix-store they must be world-readable, right?

One could put a reference to files outside the store in configuration files, but then you loose a bit of the determinism of NixOS and it’s not always easily possible with third-party software to load e.g. passwords from an external file anyways.

Besides the learning curve, that was the single big problem which kept me from diving deeper into the nix ecosystem so far.

Nix is one of those tools where you don’t know what you aren’t getting until you get it. There are so many things wrong with this post

I have to disagree, but not with the second sentence - I was sure as I wrote the post that it was full of misconceptions and probably outright errors. I wrote it in part to capture those in the hopes that someone can use them to improve the docs.

But to disagree with the first sentence, I was keenly aware through the learning and writing that I was missing fundamental concepts and struggling to fill the gaps with pieces from other tools that didn’t quite fit. If there is indeed a whole ‘nother level of unknown unknowns, well, that’s pretty disheartening to me.

In practice though, C++ throws, Rust panics, I think only well-written C code would have a chance of behaving ‘correctly’ in this case? And that’s the kind of low-level process that’s unlikely to be selected by the OOM killer.

So effectively, letting the application deal with it equals letting the application crash. The application that runs into this situation can be whatever application happens to need an allocation at some point. That seems more random than what the OOM killer targets?

For what it’s worth, I’ve been a heavy user of Nix, NixOS and Emacs for years, but still haven’t bothered configuring Emacs with Nix. The Emacs package I use is emacs25.override { withGTK2 = false; withGTK3 = false; } (this causes it to compile with the lucid toolkit, avoiding http://bugzilla.gnome.org/show_bug.cgi?id=85715 ). I do everything else with a ~/.emacs.d that’s been growing for years, across various distros, and is a mixture of Emacs Prelude (which I started with), ELPA/MELPA/Marmalade and (more recently) use-package. I just install any dependencies into my user profile or NixOS systemPackages. Actually, I define a package called all which depends on everything I want; that way I can keep track of it in git, rather than using commands like nix-env which can cause junk to accumulate. It looks like this:

with import <nixpkgs> {};
buildEnv {
  name = "all";
  paths = [
    abiword
    arandr
    audacious
    cmus
    (emacs25.override { withGTK2 = false; withGTK3 = false; })
    gensgs
    mplayer
    picard
    vlc
    w3m
    # and so on
  ];
}

There are certainly some aspects of Nix which require “buy in” (it looks like Guix is slightly better in this regard), but there are others which allow “business as usual”.

For example, if you want to make a Nix package that just runs some bash commands, you can try runCommand, e.g.

with import <nixpkgs> {};
runCommand "my-package-name" {} ''
  # put your bash commands here
  # the "result" of your package should be written to "$out"
  # for example
  mkdir -p "$out/bin"
  printf "#!/usr/bin/env bash\necho hello world\n" > "$out/bin/myFirstProgram"
''

Whether this will work obviously depends on what the commands do, but if it works then it works (you can even run stuff like wget, git clone, etc. if you want to; although I’d include a comment like TODO: use fetchurl or fetchgit). If your scripts need env vars to be set, put them between the {}. If you want some particular program available, put buildInputs = [ your programs here ]; between the {}.

Another example is programs which assume the normal FHS filesystem layout: making them work is sometimes as easy as using steam-run (e.g. https://www.reddit.com/r/NixOS/comments/8h1eu5/how_do_you_deal_with_software_that_is_not_well/ ).

Whilst there’s complicated infrastructure in Nixpkgs to support packages which use Python, Haskell, autotools, etc. sometimes we can get away without having to go ‘all the way’ :)

When starting out I just built a few packages from source in the traditional way to make them work the way I was used to, perhaps that could work with emacs and install into home initially. (I don’t use emacs, sorry I can’t help more.)

You’re not alone - I installed NixOS recently and like what I’ve seen, but haven’t been able to put in enough time to get over the learning curve yet. Until I do, I’m fairly sure I’m missing several chances to “do things properly” because I’m not sure what that looks like under NixOS. This post and comments have been quite reassuring at least!

I guess that’s the beauty of open source - now we all have to go and fix the documentation?