nearting

You can use uBlock Origin to filter those out, though for a site that you'll only visit once, it probably isn't worth it.

These types of subscribe overlays, especially for a company blog with a product that aims to compete on features/pricing, are really unnecessary and annoying.

jfc, do marketing teams for this stuff even try to hide themselves anymore?

This seems very much aimed at teams on paid tiers at competitors (which admittedly makes sense).

As an individual user, I find their feature set (https://www.neeto.com/neetocal/features) a bit underwhelming - they present a number of features as things that really any scheduler should have:

- different meeting durations

- time zones

- custom availability

- cancellation/rescheduling

- buffer time

- integrations with Zoom/Google/etc (but not CalDAV, somehow)

- email notifications, OTP and SSL (what is this, 2013?)

Personally, I use cal.com, which has all of that, plus is open source and self-hostable. And it interfaces with CalDAV so I'm not locked into Google Calendar.

You could use cal.com (one of the competitors mentioned in the post). The use case you described would fit into their free tier.

The platform is made for booking but you can use it to show your availability, by allowing people to request meetings and then not accepting any of the requests.

I noticed the Storage Share page doesn't mention anything about server-side encryption - is this an option?

The ten countries: Palau, Micronesia, Marshall Islands, Nauru, Kiribati, Solomon Islands, Tuvalu, Samoa, Vanuatu, Tonga

Let's be clear here: this is about protein folding.

I almost panicked for a moment thinking they were folding in some sort of business sense, before realizing it would take far more than what's currently going on for AWS to fold.

Not necessarily. (1) Landing pages are relatively simple to fake; just because the link goes to Google, it doesn't mean that Google has authorized an account on Amazon to sell the products. (2) Amazon has been known to mix stock, so even if the seller actually is Google, you might end up getting a product from another seller, which might not be authentic.

Personally, the last 3-4 phones I bought off of Amazon were all different models from what they had been advertised as. It's possible that you might get lucky and receive an authentic phone for less than buying from Google directly, but if you actually want confidence that you will receive the real thing, get it directly from the manufacturer.

> Ever try to share a conventional database between multiple different companies or organizations? It's not practical.

Not practical how? It seems like this criticism can only be applied to usability, but that's not a technical shortcoming.

> If you need to share a database with other companies, it inevitably leads to contracting a third party solution to manage the data entry between all parties, which means you now have to trust this one entity and there's a single point of failure.

This criticism seems a bit underspecified. While it's true that having a single entity to handle data entry results in a single point of failure, but what's the failure model? Do we assume that this single entity might be malicious? Or are we assuming that the entity handling data entry isn't familiar with the types of failures they may encounter, and thus hasn't taken steps to mitigate the effects of those failures? Both of those scenarios, given the context of sharing data among organizations, seems unrealistic.

> Hyperledger, blockchain, and the like eliminate the need for third party management. A few engineers at each party needs to set up the new service, and now you don't have to worry about central points of failure, you have built in redundancy, and you save money by not having to use a data management service that exists to make money off of you.

The claims you make here are correct: (1) the consensus protocol provides a decent mechanism for writing to the database, (2) redundancy insulates against loss of data, and (3) the open nature of the protocol means you don't have to use a for-profit service. However, there are far more efficient ways to achieve these things without relying on blockchains. If everyone that could write to the database is known, and what you want is simply to guarantee the integrity of the database, there are better data structures than a linear chain of hashed, batched events (which is all that a blockchain is, at its core).