loodish

> Not an EE myself but honestly baffled how the author got that impression with the huge expansion of RF engineering in the consumer space -

Lots of RF devices doesn't actually mean much RF engineering.

If you want 5G connectivity almost everyone buys an integrated module. Chip, antenna, and certifications included. No serious RF engineering required, no RF engineer in the building.

Those modules designers would be purchasing their chip from one of a few companies, like Qualcomm or MediaTek. Even then most of the work isn't RF engineering, it's stitching together a product and grinding through the certifications.

Much of the innovation is done away from the consumer space where certifications are less constraining.

The receiver frequency is generally assumed to be accurate. In practice the time quantization is the far bigger error and masks any frequency fault. That time quantization is why most receivers report an accuracy of 3m or 10ns.

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

Yes. Significantly safer than a Windows system in the default config.

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 finiteness of fossil fuels isn't real in a practical sense.

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.

There are much faster responses available.

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.

If you breach the LGPLv2/GPLv2 licence then you lose all rights to use the software.

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.

I like cron jobs that run during the work day. If something goes wrong I would prefer to handle it at 10am rather than 10pm. Why make life unpleasant?

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.

Folks that really care about security go for tamper evidence.

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 understand that being a fork of Snowplow is how you define yourself, but there's actually nothing on the webpage that provides any detail of what the product does, other than "event pipeline" right up the top.

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.

Absolutely. The ability to search for these flags before a commit, during a review or release is so valuable.

The vanilla vim version is

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

Documentation can be found via :help manpager.vim

The .d directories make management via tools such as ansible much much easier.

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.

Graphql is nice but there are all sorts of weird attacks and edge cases because you don't actually control the queries that a client can send. This allows a malicious client to craft really time expensive queries.

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.

By this logic an American state should remit the sales tax they collect on imported cars back to Germany. The Germans would probably love this, twice as many German products are sold in the US as US products sold in Germany.

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.

AMR (adaptive multi-rate audio codec) can get down to 4.75 kbit/s when there's low bandwidth available, which is typically what people complain about as being terrible quality.

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.