The time correction is better thought of as the fixed offset between the receiver clock and the GPS clock.

If you expose a Windows server default install to the internet it will be compromised in days. (I don't know how. I do know AWS was very unimpressed with me.)

In contrast Linux systems are often set up that way without issue.

The globe burnt about 8.8 billion tons of coal in 2024. Which is a huge amount. This is the peak, most estimates are that we will reduce from there.

Australia alone estimates that it has 147 billion tons of economically recoverable coal. That is Australia alone could supply the entire globe at peak usage for over 16 years. And Australia only has about 14% of the globes coal reserves, we can keep burning coal at this pace for at least the next hundred years. And it a hundred years the scope of what we consider to be economically recoverable will have expanded greatly, further increasing our supply.

We will cook ourselves before we run out of fuel.

For example France could gift or sell Denmark some nukes, possibly with a Rafale as a launch platform. Denmark would be an instant nuclear nation-state.

I'm not sure there is the political will though.

There's no penalty clause, there's no recovery clause. If you don't comply with the licence conditions then you don't have a licence. If you don't have a licence then you can't use the program, any version of the program. And if your products depend on that program then you lose your products.

The theoretical email would be a notification that they had breached the licence and could no longer use the software. The obvious implication being that AWS was wanting to do something that went contrary to the restrictions in the GPL, and he was trying to convince them not to.

If it really needs to run during a low load period I line it up for 6am work time. Again so that if something goes wrong it leads into the work day rather than disrupts the on-call too badly. 6am also provides a daylight savings buffer either way so you don't have to care. Recent work has all been on 24/7 operations though.

For example you can get a filing cabinet which has a lock and a counter that ticks every time it is opened. You pair it with a clipboard where you note the counter count, why you opened it and sign.

It can be picked, that can't be avoided. But the act of opening it creates a trail which can be detected. Adding a false clipboard entry is detected by subsequent users, there typically aren't many people with access.

Determining that you have a breach allows it to be investigated, mitigated. The lock is an important part of that, but it isn't perfectly secure so you manage that flaw.

Of course filing cabinets are getting rare and replaced by digital document stores, with their own auditing and issues.

I suggest putting at least some content on the website about what you do so that people can find you when looking for solutions in the industry, rather than having them adopt Snowplow and then splinter off later. I understand that your main focus is snowcatcloud.com which does have info putting some on opensnowcat.io will greatly enhance its discoverability.

Especially as the splinter strategy is going to become increasingly harder as people who care about open source won't adopt Snowplow to begin with, and people who don't care won't leave it.

    MANPAGER="vim +MANPAGER --not-a-term -"

You don't have weird file patching going on with the potential to mess things up in super creative ways if someone has applied a hand edit.

With .d directories you have a file, you drop in that file, you manage that file, if that file changes then you change it back.

So you end up having to put depth and quantity limits, or calculating the cost of every incoming query before allowing it. Another approach I'm aware of is whitelisting but that seems to defeat the entire point.

I use rest for new projects, I wouldn't say never to graphql, but it brings a lot of initial complexity.

Sales Tax, Value Added Tax, Goods and Services Tax, are all taxes on consumption. They are paid by the consumer at the location of the consumption. They aren't a tax on production or producers.

The speech codecs are complex and fascinating, very different from just doing a frequency filter and compressing.

The base is linear predictive coding, which encodes the voice based on a simple model of the human mouth and throat. Huge compression but it sounds terrible. Then you take the error between the original signal and the LPC encoded signal, this waveform is compressed heavily but more conventionally and transmitted along with the LPC signal.

Phones also layer on voice activity detection, when you aren't talking the system just transmits noise parameters and the other end hears some tailored white noise. As phone calls typically have one person speaking at a time and there are frequent pauses in speech this is a huge win. But it also makes mistakes, especially in noisy environments (like call centers, voice calls are the business, why are they so bad?). When this happens the system becomes unintelligible because it isn't even trying to encode the voice.

Lithium batteries are everywhere, most of them significantly larger than the one in a small pager. This includes secure environments like military/intelligence facilities and aircraft.

Proof that a lithium battery pack can be weaponised as a bomb, in a way that avoids easy detection, should be a significant concern to anyone who tries to maintain the security of those spaces.

The reason they were using pagers, as opposed to phones, was to avoid exactly this kind of potential attack.

Pagers are (typically) a broadcast technology, the pager has no transmission capability. A page is broadcast from every tower, it has no idea where the receiver is. A targeted page is done by the receiver filtering out and ignoring pages that it isn't the recipient for (eavesdropping all pages is trivial).

The pager device is simple, it doesn't contain a GPS or have any concept of it's own location. No microphone or audio capability, very little processing capability. And adding such capability with something like a bug would be reasonably apparent to anyone opening one up and inspecting it.

From https://www.mdpi.com/2313-0105/8/11/201

A puncture causes runaway/explosion in seconds. Overcharging takes 13 minutes. There's not good data on a dead short (because it's unlikely during normal operation), but it's going to be between those on the faster end. From personal experience a shorts cause things to get noticeably hot after about 10 seconds, the graphs show that once you hit 60C things rapidly get worse.

A relay may have been required to hold the short as the battery stops supplying voltage.