ymse

OpenBSD invented a similar protocol to VRRP called CARP back when VRRP was patent-encumbered[0].

Configuring it is deceptively simple: just create an interface with ifconfig called "carpN", specifying VID, password and IP address[1].

You can also make it load-balance traffic between your carp hosts if desired[2].

Give it a go for your next firewall/server build :)

0: https://en.wikipedia.org/wiki/Common_Address_Redundancy_Prot...

1: https://www.openbsd.org/faq/pf/carp.html

2: http://man.openbsd.org/OpenBSD-current/man4/carp.4

If you need just the floating IP address, keepalived is fine.

I'm mostly bitter from spending days tracking down a race condition stemming from its notification scripts, which wasn't really keepaliveds fault per se. But if you need to start/move/constraint/notify anything along with the IP, or require sub-second failover, Corosync/Pacemaker is a far better choice.

However due to their complexity, for just a floating IP address, keepalived is unfortunately the best option for Linux (I usually have OpenBSD in that spot).

I'm amazed no-one has mentioned "dwb" in this thread. Yet another webkit-based browser with vi-like keybindings, but also an extension manager and plugins such as adblock and requestpolicy. Entirely keyboard-driven.

http://portix.bitbucket.org/dwb/

The title is misleading. It's not a DNS service, but a node.js hosting platform similar to Heroku.

Custom domain is not included in the free tier: https://zeit.co/now#pricing

If you're on a paid plan, you'll get Geo-DNS for "free".

From the systems/operations side of things..

Ganeti: rock solid clustered virtualization suite.

OpenBSD: no fuzz server/router distro.

Ceph: clustered network storage without tears.

Varnish: covers any HTTP needs. Add haproxy or nginx for HTTPS.

Corosync/Pacemaker: Designed for reliability. Leave VRRP where it belongs (I'm looking at you keepalived).

xCAT: Little-known but widely used datacenter lifecycle management suite. Comes with cluster-aware shell, native remote consoles, BMC provisioning, unattended installs, DNS and much more.

Guix: The package manager for the future.

Things that make me want to tear my eyes out:

Openstack: keeps breaking inexplicably, nightmare to configure and maintain. Terrible documentation.

Vyatta: Don't even want to talk about it.

RHEL: Upgrades systemd 207->219 in minor release. Backports unstable kernel patches. Requires EPEL for lots of standard software. RabbitMQ logging has been broken more than two months (BZ 1324922).

Having used uMatrix for years now, I can't imagine browsing without it.

A couple of tips for your ruleset:

* disable first-party plugins (flash, PDF)

* enable first-party "other" (html5 video, audio)

I also enable various CDNs globally, i.e. scripts from cloudflare cdnjs, and frames/video from youtube and vimeo. Though I don't really recommend this if security/privacy is a concern. At least they won't get your cookies :)

Edit: oops, just noticed you accept first-party everything. Still, disabling plugins should prevent a wide class of exploits (see recent Chrome PDF vulnerability).

The tests are wildly inaccurate, and MBTI itself is not the full story of cognition and personality, but I think there is enough evidence suggesting that the cognitive functions as described by Jung[0] are very real.

The article you linked to uses lack of MBTI in psychology journals as an argument against its validity, but its applications in the field are very limited. You're more likely to find MBTI references in neuroscience journals as there are appears to be clear correlations between type preferences and brain activity patterns[1].

Even so, knowledge of a persons cognitive preferences just isn't very useful. So the main application of MBTI is indeed "just for fun".

0: http://psychclassics.yorku.ca/Jung/types.htm

1: https://www.youtube.com/watch?v=MGfhQTbcqmA

> They issued fraudulent SSL certificates in 2011: https://www.schneier.com/blog/archives/2011/03/comodo_group_...

Moxie had an amusing anecdote about this incident in his Blackhat 2011 talk "SSL and the future of authenticity"[0]. Apparently the same IP as was used by the "sophisticated attacker" and disclosed by Comodo downloaded sslsniff[1] from moxies server the next day, referred by a video tutorial about intercepting SSL..

0: https://youtu.be/Z7Wl2FW2TcA?t=5m

1: https://moxie.org/software/sslsniff/

The above is how most people first configure tmux, since C-b is just awkward. `bind-key C-a send-prefix` is optional of course, but is used to forward C-a to the active window (beginning-of-line in shell and emacs). How would you do that in screen?

The default for `previous-window` is `prefix-p`. Run `tmux list-keys` to see all active bindings.

Why don't you just change the prefix key instead?

  unbind C-b
  set -g prefix C-a
  bind-key C-a send-prefix

I use C-z FWIW.

Wait, what? A perl app distributed through NPM? What's next, a node app on CPAN?

Color me perplexed.

Frankly, I find hard-coding #!/bin/bash sensible in a large corporate setting such as Google. It prevents PATH manipulation and they obviously have a uniform and controlled environment.

Bash arrays can be convenient, but at that level of complexity Python or Ruby are much easier to read and understand (and necessarily maintain).

Except they do even with `set -e`. Especially if you forget to/can't set `pipefail` (which is bash-specific).

Or consider the last example from the wiki link above:

  set -e
  f() { local var=$(somecommand that fails); }
  f    # will not exit

I tend to avoid `set -e`. To borrow the Python adage: "explicit is better than implicit". In shell it translates to "if you need error handling, add it where necessary".

See http://mywiki.wooledge.org/BashFAQ/105 for some (most) of the pitfalls.

> Executables must start with #!/bin/bash

I've started using #!/usr/bin/env bash for compatibility with non-FHS distros such as NixOS.

Happy to see arrays omitted; if you find yourself in need of bash arrays you should definitely consider a proper language.

I tend to stick to POSIX shell to the extent possible, but readonly variables and [[ ]] syntactic sugar makes sense when maintainability is more important than portability.

That's pretty much the tagline of mutt[0].

> All mail clients suck. This one just sucks less.

I've become really fond of notmuch[1]. It's basically a mail database and library with really fast search, tags, and native support for threads. Numerous front-ends exists[2]; I use the bundled emacs client, but have wanted to try out nevermore[3] (it did not work well with Evil last I checked).

0: http://www.mutt.org/

1: https://notmuchmail.org/

2: https://notmuchmail.org/frontends/

3: https://github.com/tjim/nevermore

The author is also active in this thread:

https://www.reddit.com/r/linux/comments/4m4mko/i_made_a_site...

DDG dug up these:

http://www.techtimes.com/articles/3930/20140303/heres-how-a-...

http://www.theverge.com/2014/2/28/5458610/fake-google-maps-l...

Needs (2015) tag. See also the official release announcement[0] and documentation[1].

0: https://coreos.com/blog/rkt-0.8-with-new-vm-support/

1: https://github.com/coreos/rkt/blob/master/Documentation/runn...

A proprietary (and solid) alternative to Lustre would be GPFS, which also has a long track record in HPC (and other markets in which IBM thrives).

As someone who completely shares your Lustre sentiment, I can't fathom why Intel keeps pouring resources into it.

Docker supports native RBD since version 1.8. Which should be both faster and more reliable than using the S3 gateway (though that has other benefits and becoming pretty good too).

Native RDMA support for Ceph is still a ways off. The current implementation requires disabling Cephx authentication, which is a no-go in any environment where you can't completely trust every client (e.g. "cloud", where most current deployments/users live). It also hasn't seen much development since the initial proof-of-concept (still highly experimental).

That said, IPoIB should work just fine, and the main bottleneck currently is (Ethernet) latency. I'm running a couple of 1,6PB clusters (432 * 4TB) and can only get 20-60MBps on a single client with a 4kB block size, but got bored of benchmarking after saturating 5 concurrent 10Gb clients with a 4MB block size.

I do expect the RDMA situation to improve substantially over the next year or so, even if authentication will still be unsupported. The latter generally isn't a problem in HPC where stuff like GPFS lives (where you also have to trust every client). And they clearly want that market now that CephFS is finally deemed production ready.

The default bash setting is to not write history until the session terminates. In which case the whole session will be forgotten, not just the stuff after overwriting HISTFILE (I always set it to /dev/null FWIW, didn't know blank was sufficient).

You can just uninstall it and use something else to configure networking. It's one of the first things I purge on any distro.

With systemd it's not so simple.

I enjoyed Natas[0] some years back, which is a simple and relaxed web security (only) challenge. They have other games too, no login required.

0: https://overthewire.org/wargames/natas/

I prefer uMatrix[0] (by the uBlock author) which gives absolute control over third (and first) party requests.

I don't even subscribe to the built-in Adblock filter because of my default-deny rule. It also negates the need for Privacy Badger and similar.

See the screenshots for how it works (similar to, but more granular than, uBlock advanced mode).

https://github.com/gorhill/uMatrix/wiki/Very-bare-walkthroug...

https://github.com/gorhill/uMatrix/wiki/Examples-of-useful-r...

0: https://github.com/gorhill/uMatrix

Then start your process with `systemd-run`. nohup is so three decades ago.. :(

I get your sentiment. I only started using Salt some months ago, but it was really a breath of fresh air compared to Puppet. However it took me a while to realize its true strengths since the documentation is very...dry.

IIRC Ansible, like Chef, does serial execution. That is, states are applied in the order they are written. I think that's part of the reason it has gotten so popular, as you'll have very few surprises in the vein of "what do you mean there is no ntp_service -- it's right there next to the config declaration!".

What Salt got right is the pillar, for which the Puppet equivalent (Hiera) was an afterthought. The Salt engine allows you to generate states from the pillar, rather than making poor clones of Puppet modules (as most of the formulas I've seen online).

However that flexibility is not documented anywhere, nor part of best practices. Nevertheless I'm about to release a set of formulas that are truly pillar-driven with no hard-coded stuff. Keep an eye out for the accompanying blog post :)

Of course, if you don't care about data/code separation and just want to get stuff done, there are better tools. And if you have full control of your environment, I would strongly suggest using Guix and/or Nix rather than these legacy configuration management tools.

Which design flaws are you referring to? As a recent Salt convert (and Puppet expert), I was perplexed as to why such a nice tool would have a man page 40x longer than bash.

Turns out it includes extensive documentation for all states supported by Salt, generated from the online documentation. Compare this to the Puppet manual:

    $ man puppet
    PUPPET(8)                Puppet manual                         PUPPET(8)

    NAME
       puppet

       See ´puppet help´ for help on available puppet subcommands

Obviously no-one will be using everything that Salt supports, so it would be nice if it was broken into sub-sections. But I much prefer having all documentation available in a manual to looping through every module and run "rdoc" as in the Puppet case.

Any sufficiently popular configuration management tool will have equally long documentation.

There are a couple of simpler options available:

http://www.nico.schottelius.org/software/cdist/

https://github.com/brandonhilkert/fucking_shell_scripts

I always keep this in mind when building fault-tolerant systems:

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

And user interfaces:

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.