lfam

I'm sympathetic to your complaint, but consider that 85 dB is quieter than an unamplified symphony orchestra or the cabin of most cruising airliners.

A good club sound system doesn't actually need to be very loud. It will still be loud enough that long-term exposure will cause hearing loss, but not loud enough that you would be shocked when you walk in the room.

Unfortunately, a sound system of that quality is extremely expensive and requires skilled workers to operate each night, so only clubs in places that allow clubs to operate openly and make money can afford it.

If a city doesn't allow clubs to stay open all night, or if the police crack down on drug use, the clubs go underground and don't make any money (or won't invest it in equipment that may be confiscated). Then, they use lower-quality equipment that must be played too loud in order to fill the space, and don't hire sound engineers to operate the system properly and safely.

'Testing' is also usually the last branch to get security updates, sometimes weeks later.

At least in the United States, driving a car on public roads is a privilege doled out by the states. There is no right to drive a motor vehicle here.

> That would imply that there is no security benefit whatsoever provided by a DV certificate.

The security benefit is that the connection to the server is authenticated and encrypted. Nobody in between can inspect or mutate the data. This is a huge win over unauthenticated HTTP.

I don't think this is a problem.

If those sites should not be allowed to own the domain names they are using, then the registrars can take the names back.

All the DV certificate means is "you are using an authenticated connection to the server that answers for foo.com".

TLS doesn't have anything to do with the ethics, morality, or legality of the site operators.

It's too bad that we've trained laypeople to think otherwise. But, even a phishing site should be served over HTTPS. Otherwise, the user will be vulnerable not only to the phishing site, but every intermediate server that the connection passes through.

I'm also using borg, to a server I control and also to rsync.net.

Essential and small files like keys (which may be necessary to "bootstrap" the backup in case of complete failure of my workstation) are copied and verified manually to offline storage.

Marilynne Robinson's book 'Mother Country: Britain, the Welfare State, and Nuclear Pollution' talks extensively about the history of Britian's social welfare system and its degrading effect on the people it ostensibly serves.

I recommend it highly if you are interested in the relationship between people and states of the British colonial diaspora, including the USA.

OpenSSL 1.0.1f is completely unsupported by the OpenSSL project, as that advisory points out:

Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates.

Since 1.0.2 is not vulnerable, it seems unlikely that the bug would be in 1.0.1.

It's interesting to think about where to find this information.

Big ISPs have access to these "honest" signals on a large scale.

One of the biggest pharmacy chains in the USA (CVS) has stopped sale of tobacco products. You can't even buy a cigarette lighter.

There are no "legal" music stores that approach the breadth and quality of the music library that was available on what.cd.

As the music industry's revenue stream changes from music sales to low-bitrate streaming services, we will see our shared musical heritage regress to the pre-compact-disc era in terms of audio quality and long-term availability.

We'll be lucky if recorded music of today survives long enough to exit copyright and be added to public libraries before being lost forever, or at least before we lose the "master" recordings.

That sounds interesting. Can you explain how to do it?

All their software is open source. You can run both the client and the CA server on your own.

But your CA server won't be able to sign any certificates that will be recognized by Mozilla, Google, Microsoft, etc. It takes time, energy, and expertise to be a CA authority that is trusted by those organizations.

I think that trying to scrimp and save is not worth the relatively small amount of money saved for something like this. We've seen over and over again that so-called "critical" open source projects cannot afford to operate that way.

Perhaps, but it depends on your needs.

When using PGP, you have to decide how much you trust each key. All that PGP does is enforce your trust preferences.

$2 million (or whatever number) may be the standard rate used to compensate others for a lost life, but does anyone willingly sell their life for $2 million?

I think there is a difference between how we try to compensate for the loss of something irreplaceable (a life) or disincentive negligence, and the price of something bought and sold.

There is a new project, Software Heritage [0], that specifically addresses the problem of long-term code availability.

https://www.softwareheritage.org/

Citation?

> I mean, what's the big advantage of Docker and the whole "container" movement? You are guaranteed (more or less) to have a known state. Why does resetting hardware fix problems? Because it resets things to a known state. Managing state is the problem, and functional paradigms are the solution.

I would argue that, with Docker, you may or may not have a known state. You certainly have a fixed state, but whether or not the state is "known" depends on how you generated it. If you use something like Nix (or Guix) to create the image, then you have a chance of knowing the state and being able to understand it. But if you build the image in some other way, there's a good chance that you won't be able to understand the relationships between the components, and that you won't be able to change the relationships safely and effectively later on.

You can have your house blurred out in the USA, too.

> We don't want it so that everyone is forced to build everything from scratch every time.

We don't want this either :) Let's not boil the oceans.

Nix and Guix are both a hybrid of build-from-source and binary package management systems. The package recipes and management tools describe how to build some software from source, and then transparently provide binaries for those recipes when the binary is available from a user-approved provider of the binaries.

But, by providing the full build recipes, all the way down to the bootstrap, users can easily rebuild binaries from source to check that their selected binary provider is honest, or to find reproducibility bugs.

In the case of a package recipe for some software that does not have source code available (a binary "blob"), the recipe would just download the blob from somewhere. We don't package those things in Guix, whereas Nix does. Although, it's not hard to make custom recipes that would do that, if you wanted to.

You're right, I forgot about the GPU. I consider that a very optional part of the computer.

I've also used an A20 for compilation... briefly. And not much was compiled in the brief period ;)

As for the boot ROM blob, do you know if that is the 'boot0 and boot1' that Olimex apparently published the source code for?

http://linux-sunxi.org/BROM#Source_code_for_boot0_and_boot1

My understanding is that the Allwinner A20 is one of the very few systems produced today that can be used with 100% free software. Not that Allwinner themselves helped very much, from what I've read — the sunxi community has spent a lot of energy on reverse engineering.

Streaming is convenient, but I think it's not a substitute for CDs. The value of CDs is that they provide a canonical and lossless recording, which isn't provided by vinyl, tapes, or streaming services (AFAIK).

Of course, lossless digital audio files are even better.

Ah, I misunderstood. Thanks for explaining.

It might be a disadvantage to take off uphill, but I believe that it's desirable to take off into a head wind.

The wind generates some of the lift required for take off, and by taking off sooner there is more runway available in case you need to make an emergency landing.

One of the design choices of Unifont is to trade quality for coverage:

"Unifont is a creation of Roman Czyborra, who in 1998 lamented that seven years after Unicode's first release, there was still no single font that could display all Unicode characters. He suggested that if expectations of font quality were lowered to that of a bitmapped font, achieving coverage of Unicode would be easier."

So, if you render everything with it, it won't be very pretty. But it makes a great fall back option for missing glyphs.

source: https://savannah.gnu.org/projects/unifont

I used a search engine and found this list of enforcement actions against businesses:

https://www.fcc.gov/general/u-nii-and-tdwr-interference-enfo...

After reading a few of those reports, you should learn enough of the terminology to effectively search further.

Can you provide a reference for this?

This is my take on the subject as a person who has worked professionally in FM radio regulatory compliance in the USA.

The FCC's approach to regulation of the electromagnetic spectrum is that it is a "common good", i.e. it is rivalrous but non-excludable. In their view, nobody has a right to use the spectrum in the USA. They grant licenses to use it, and they can tell you how to use the spectrum you are licensed to use.

Apparently, there were documented problems with WiFi radios being operated outside of their licensed parameters and interfering with safety critical airport radar systems.

It's probably too late to persuade them to change their minds. The public response to this topic was voluminous. They received way more comments than they usually do, but they still chose this approach.

If you care, you should choose to support hardware vendors that make the effort to separate the WiFi radio from the main system, allowing you to install your own firmware.