dan

Most countries have a code you can dial before a number to hide the caller ID. It's #31# in Australia and *67 in the USA.

Technology has still ruined it though, since most people don't pick up calls from private numbers any more because a lot of them are spam.

I miss Yahoo! Answers sometimes. A simpler time where dumb things and misinformation online was mostly contained in small niche areas rather than being broadcast to tens of millions of people on TikTok.

I'm very curious about how much bandwidth it consumes. Even with the small amount of content, I wouldn't be surprised if it's over 1Gbps.

The code they're analyzing is free and open-source though, so they can already use it this way. One of the freedoms of free software is that people can study it and use it however they want, for whatever purpose they want.

Isn't it good that they're sharing data with the projects instead of just keeping it for themselves?

Whether your co-op can buy cheaper than Colesworth retail prices is a different matter.

Some people are willing to pay a bit more if it means supporting a community store over a big corporate one.

I'm living in the USA now, and there's a lot more supermarkets here. In my area in California, there's a few local chains with 3-4 stores, some co-ops, and the major stores. The biggest supermarket (Walmart/Sam's Club) only has 20% market share, and even the top 5 companies (Walmart, Kroger, Costco, Albertsons and Ahold Delhaize) still only account for 44% market share. The top 3 in Australia (Coles, Woolworths, and Aldi) account for around 75% market share.

All three are defined by the license.

Some software is "source-available", meaning you can see the code but it's not open-source. Microsoft uses to do this a lot with the .NET Framework (they called it "shared source"), before they created a new version that was open-source from the beginning.

One of the issues with this type of code is that it often taints you. With the old .NET shared source for example, you weren't allowed to redistribute the code or use it for other purposes. if you ever looked at that source code, you weren't allowed to contribute to competing open-source projects like Mono, since they had no way to guarantee that the code you were contributing wasn't influenced by what you saw in the shared source, or that you didn't just copy and paste it from Microsoft's code.

There's some popular self-hosted projects that are source-available rather than open-source, like n8n and Sentry.

These days it's more common for software to be "open core", meaning the core functionality is open-source, but extra stuff around it is only source-visible with a proprietary license, usually requiring a paid subscription to be allowed to use it.

Free- and open source is not the same!

You're right, but in reality it usually doesn't matter. All common licenses (GPL, LGPL, MIT, BSD, Apache, MPL) fit both definitions: free software as defined by FSF, and open-source as defined by OSI.

It's only really niche licenses where it differs - for example NASA's Open Source Agreement is open-source (OSI approved) but not free (not FSF approved) because of this clause:

Each Contributor represents that its Modification is believed to be Contributor's original creation and does not violate any existing agreements, regulations, statutes or rules, and further that Contributor has sufficient rights to grant the rights conveyed by this Agreement.

This is what the FSF say about it:

The NASA Open Source Agreement, version 1.3, is not a free software license because it includes a provision requiring changes to be your “original creation”. Free software development depends on combining code from third parties, and the NASA license doesn't permit this.

Note that "free" refers to freedom, not price. Both definitions allow you to charge money for the software. However, you can't restrict the user's freedoms, so someone that buys the software could give it to someone else for free, and you wouldn't be able to stop that while still remaining FOSS.

Makes sense! I didn't realise it has a UI.

I've got a bunch of snippets in /etc/nginx/snippets/, so for example I just need to add include snippets/proxy.conf to a server block to add most of the configuration needed for a reverse proxy. I've been using Nginx for long enough that I just write the rest of the server block by hand.

I'm just using regular Nginx, which I've been using for 20 years. What does Nginx Proxy Manager or npmplus do better?

I've been meaning to try Angie too, which is a fork of Nginx.

Caddy is a good piece of software.

I've been using Nginx for 20 years and don't really have a reason to switch, so I'm still using it. I use certbot, so it's just one command to create the certificate initially, and then it auto-renews automatically via a systemd timer.

A private key leaking is bad, since anyone with the private key can decrypt data that was encrypted with it.

Traditionally, the way that leaked certs were handled was via Certificate Revocation Lists (CRL). CRLs contain lists of revoked certificates - their serial number, revocation date, and the reason why they were revoked.

However, CRLs are imperfect. Checking for revoked certificates every time you go to a site would slow things down a lot, as the lists are now too large to check and download real-time. Modern browsers and other TLS clients periodically download the lists in the background. Also, it might take a while between when the certificate is compromised and when the company notices the compromise.

Because of this, the CA/Browser forum (a group with all the major browser and TLS certificate vendors) have started dropping the max lifetime of certificates. The idea is that even if a private key does leak, the time frame that it's usable for will be significantly shorter and any leaks should (in theory) cause less damage.

• The original maximum duration was 39 months: Three years plus an extra three months leeway for obtaining and deploying new certificates.
• March 2018: Reduced to 825 days
• September 2020: Reduced to 398 days
• March 2026: Reduced to 200 days
• March 2027: Planned to reduce to 100 days
• March 2028: Planned to reduce to 47 days

All modern deployments, regardless of if they're using free or paid certs, should have their renewals fully-automated, so in theory the validity period shouldn't matter as much as it did in the past. All major vendors (Let's Encrypt, DigiCert, Sectigo, GlobalSign, AWS, SSL .com, etc) support ACME now. Reducing the validity is also a forcing function t o ensure automation is actually implemented.

somehow else in the middle and just can “ignore” certs renewals?

I'm not sure that's possible, since an attacker in the middle shouldn't be able to obtain a valid certificate for the domain. Certificates have a "not valid after" date encoded into them, after which the certificate is considered invalid and you get an error.

biometric, personal, behavioral and health data

What data are self checkouts collecting that regular checkouts aren't?