@mulander @canadianbryan @phessler funny you didn't question pulseaudio > sndio :D

So, for me gnuscreen ~= tmux because I don't know how to use either.
As for iptables vs pf, haven't really tried pf, so kinda trolling. But I do like iptables syntax.

@Wolf480pl @canadianbryan @phessler uhm, sndio is miles better.

If you ever try pf you will never want to look at the iptables config again. It also has a bunch of feature you probably think are impossible in a firewall :)

@mulander @Wolf480pl @canadianbryan @phessler
Any idea if nftables is more like pf?

@canadianbryan @Wolf480pl @phessler he said he likes the iptables syntax :P

@canadianbryan @phessler ok, let's remove the obvious troll ones, and the "I have haven't tried yet" ones.
We're left with:
scrypt vs bcrypt
git vs cvs
i3wm vs any other wm
/dev/urandom vs getentropy

@Wolf480pl @canadianbryan @phessler nano v.s. emacs

@phessler @canadianbryan @Wolf480pl with the obvious winner being the former

@Wolf480pl @canadianbryan git is a gigantic pile of poo. who cares about *wm?

devurandom is a problem because of libraries and chroot, but getentropy is an amazingly shitty implementation of arc4random.

@phessler @canadianbryan for devurandom, don't you have bind mounts? or mknod?

@Wolf480pl @canadianbryan you can't mknod on a filesystem mounted with nodev. or when you are out of file descriptors. or are using pthreads. etc. http://man.openbsd.org/arc4random.3

@canadianbryan @Wolf480pl shit, my bad. I mixed up getentropy() with the linux version that is massively limited.

@phessler @Wolf480pl @canadianbryan CVS is even more a pile of poo than git.

@samis @phessler @canadianbryan and it has a SPOF

@samis @Wolf480pl @canadianbryan

Having used both in production settings: I corrupt my git checkout about once a month.

I haven't corrupted my cvs checkout in 15 years.

@phessler @samis @canadianbryan I've been using git for all my side projects, university assignments, and at work, and I never corrupted a checkout.

Maybe you're more familiar with CVS and it works ok for you. But for me, the decentralized nature of git is a must.

@Wolf480pl @phessler @canadianbryan Me neither, though I have managed to screw up my git history a few times. On the plus side there's alternatives if you don't like git such as mercurial.

@phessler @Wolf480pl Some obvious herrings, iptables horrible syntax not withstanding, it is a bunch of comments in a shell script vs. pf's atomically loaded configure file.
man-db isn't really an implementation, is the actual Linux manuals, plus groff, written in C++. mandoc is a new man/mdoc parser toolkit in C. Linux manuals vs. BSD manuals (written in the semantic mdoc(7) language)? Yeah, right.

@Wolf480pl @phessler /dev/urandom vs arc4random? Again, where to begin. First of all, Linux is often starved for entropy at early boot, and blocks. On OpenBSD, high quality random numbers are available very early (kernel is seeded by boot loader), as for getentropy, which seeds userland arc4random(4), it was designed to work without exhausting open file descriptor limits.

@canadianbryan @phessler
no, /dev/urandom vs getentropy.
Why do you need separate syscall for reading random bytes?
Reading bytes == what files are fore.

@phessler @canadianbryan for*

@Wolf480pl @phessler Exactly as explained, in chroot constraint environments, it's often on Linux for example to fall back to poor time seeding if opening /dev/random fails! getentropy works in chroots.

@Wolf480pl @phessler comments = commands*

@canadianbryan @phessler so are you saying your kernel has a hardcoded path to where the firewall config should be? ewww....

@Wolf480pl @canadianbryan no, pfctl(8) feeds the file into the kernel. the kernel itself doesn't read it.

@phessler @canadianbryan so how's that different from iptables-restore parsing the iptables config and feeding it to the kernel?

@Wolf480pl @phessler It's not atomic, it's just chaining iptables commands..

@Wolf480pl @phessler Plus there are many other quality of life things that make working with pf far nicer than iptables, especially when debugging rulesets.. for example, pflog(4).

@Wolf480pl @phessler No, rulsets are parsed in userland (pfctl) and loaded atomically into the kernel.