Cloud storage, eh? That sounds like a super-reliable storage solution, hehehe!

I'm fairly sure that Albini hangs on to his analog tapes for sentimental reasons, but you misunderstand one point: he says he prefers to give a band a tape as a master for safety reasons. That means a physical copy that can reasonably ensure the band that down the line they will still have their music. The volatility of a digital file is probably not because he thinks people will forget how to read PCM audio, but simply because the file will easily be lost.

I'd like to see the frequency response graph of a "properly aligned Studer" up to 80kHz. Response curves in the audible band: http://www.endino.com/graphs/

Well, what you wrote is based on ignorance of signal processing (don't worry, I'm at best a dilettante myself!)

The basic waveform is, per Fourier analysis, a sine wave. Any other waveform is composed of a fundamental sine wave plus higher frequency sine waves. A perfect square wave requires composition of an infinite number of sine waves, and hence also requires an infinite bandwidth and as such is not physically realizable!

When human hearing is stated as being capable of recognizing frequencies up to 20kHz, the waveform is implicitly a sine wave. It's not possible to hear a 20kHz square wave, because what makes it a square wave is the addition of higher frequency sine waves which are inaudible.

Nyquist's sampling theorem, on which digital audio is based, states that to perfectly reconstruct a band-limited signal, the sampling frequency must be at least twice the highest frequency component[*] of the signal. That means that to capture a 20kHz band-limited signal, it is necessary that the sampling frequency be above 40kHz, but if this is fullfilled, a 20kHz sine wave can be perfectly reconstructed! However, a 20kHz square wave _cannot_ be captured without aliasing because of the higher frequency sine waves present, it is in fact not band-limited to 20kHz!

[*] Actually the Nyquist theorem really states that the sampling frequency must be at least twice the bandwidth of the signal. It's possible to perfectly sample a single 20Khz sine wave with a much, much lower sampling frequency, but the signal will be folded down, which is not actually destructive as long as there aren't other frequency components interfering. This form is known as "undersampling" and is used in some radio receivers to down-convert the signal.

Why would you expect no references to FreeBSD, if they are using it? The license requires them to put such references.

Please explain how "const can fuck you hard in OOP".

I actually doubt JRR Tolkien would disagree with what the estate does...

I agree with your opinion on Jackson's films, but the deal with the films were actually struck with Tolkien himself who, as I recall from Letters, saw two paths to making films out of the books: artistic integrity...or money. And he decided to go with the money. This produced the bad cartoon film (which strangely enough I actually recall more fondly than the Jackson's films but I think that might just be my rose-tinted spectacles.)

Packages are not part of the base system, so it's not so strange that the documentation doesn't refer to the wide-dhcpv6. I have checked now and it was indeed wide I was using. But I have actually disabled it now and using ipv6 autoconf instead.

It appears the FreeBSD packet filter is actually a port of OpenBSD's PF. If nothing's changed, OpenBSD's PF is single-threaded, so if all the box is going to do is to filter packets, more cores won't improve things. I don't know if FreeBSD have threaded their port, or otherwise made performance improvements.

I think a DHCP6 client/server might not be included on the same level as DHCP4, but there absolutely is an option to install a working one, since I'm indeed using it. A quick scan shows the "wide-dhcp6" in packages, but I'm not quite sure if this is the one. I can check later when I get home if you want?

What I meant was that I set up an IPv6 over IPv4 tunnel on my openbsd box which then acts as a IPv6 router for my LAN. IPv6 packets are routed to and subjected to the OpenBSD firewall just like IPv4 packets. I also have DHCPv6-server running to deal with computers on the LAN getting proper IPv6 addresses. In other words, my setup sounds pretty similar to what you are asking about. If my ISP offered native IPv6, that would actually simplify things as it would mean one less step as I wouldn't need the tunnel anymore.

OpenBSD does include a DHCP6 package (or maybe it's in ports, I honestly don't remember, but anyway, it works). PF does support IPv6 filters, exactly the same as IPv4 as far as I can discern. As for routing protocols, I have no experience with them, but OpenBGPD does appear to support IPv6.

I have run OpenBSD as my firewall since forever, and have since set up a tunnel to give my LAN IPv6 connectivity. There has been absolutely no problem with IPv6 at all in OpenBSD[*]. Every application I've messed with, from packet filter to tunneling to DHCP to nameserver supports it. Granted my usage is probably very limited still, but my impression is that IPv6 is supported pretty much everywhere that IPv4 is. I can't say how this compares with FreeBSD though, because my experience with it is restricted to a brief laptop install circa 1998 (although, I was briefly considering installing it on a desktop machine this weekend actually!)

[*] Well, actually, one of the remote holes in the default install actually was in the IPv6 implementation, but that was before I set up my tunnel fortunately!