ProblemFactory

It seems to me that the main source of confusion is about the independence of Redis from Redis Labs.

To you Redis is an independent open-source project, to which Redis Labs generously donates your salary so that it you can work on it full time.

But to most people online, that is not immediately obvious: because of the company name, you working at Redis Labs, and them being the main sponsor, Redis is seen as the "open-source core product" of Redis Labs. https://redislabs.com/community/oss-projects/ also strongly leaves that impression - it even says that to contribute to Redis you have to sign the contributor agreement with Redis Labs.

Once you have that impression, it's natural to assume that Redis + Redis Labs modules are part of one product family, and that the roadmap for both is being planned based on the business goals of Redis Labs.

> It is good that it's so simple to file it, but at least when just texting an okay it probably hides just how much people pay in taxes.

There are much better ways to make taxes understandable to people than making it complicated to file them.

For example, UK tax office sends everyone a letter with their total tax contribution and a breakdown on how it is used for different government services: https://i.imgur.com/a1MIiPC.jpg

Do you have suggestions on whether to deploy simple (functional - no state or external resources used, except perhaps usage tracking) APIs as cloud functions or on the App Engine? What would be the "turning point" when it's best to start considering App Engine?

The problem I see is that jamming GPS / wifi / mobile frequencies once you see a suspicious drone is too late. When the drone is already in view, it can find its target by inertial or camera navigation alone.

But jamming 1km around every possible target, every day as a precaution is going to be too disruptive. It may actually increase risk to life - by jamming 911 calls for any ordinary accident.

Unfortunately many cheap GPS chips use the (incorrect) or definition, not and. It was a pain to find one that works above 59000ft but very slow speed for a weather balloon project some years ago.

> encrypting tenant data at rest

I know that this is required by various security certifications - but is there a reasonable threat model that it actually protects against?

The only one I see is someone physically stealing the hard disks out of the servers, which is impossible if you are using a trustworthy cloud datacenter instead of a server in your bedroom.

That is still an extremely small minority who would upgrade.

Based on what I've seen from non-technical friends and family, the standard approach to laptops is to buy a $300 netbook, fill it with crappy browser extensions and malware over a few years, complain that the computer is "too old and slow", throw it out and buy a new one.

Firebase Database default settings make the entire database world-readable and world-writable by all "authenticated users". But once you have enabled authentication, then that means anyone who signs into your app with a Google account. Restricting users to only access their own data requires understanding and writing "security rules".

It's the most irresponsible default I have seen in practice.

Not to mention that silicon storage comes with reading and writing circuits.

IBM has also demonstrated manipulating individual copper atoms on a surface and arranging them into patterns - a scale that would be much denser than organic molecules.

Or in a much simpler and common case: you trust someone right now to run a non-modified client and not to take screenshots, for example based on a corporate policy.

Months later the relationship turns sour, and they are fired or denied a promotion. They can't then go through the archives any more to take the screenshots.

Tesla sold a $3000 "full self-driving hardware" upgrade for a while, and now advertises all cars with the same, while suggesting that the software update to enable it is just around the corner.

If they admit that radar + optical cameras won't be good enough for full self driving, there may be a lot of refunds to process.

From first principles, just optical cameras should be enough - humans can do it. But the software to make it work could be general AI level complex. Personally I think LIDAR self-driving will be available in less than 5 years, but optical may take 30 years. And the company who would be most capable of developing optical self-driving AI is Google, the fact that they are sticking to LIDAR is a good indication of the complexity of optical.

I think one of the main issues is that the current employment classification is too binary. There are independent contractors, who are really independent small businesses: set their own rates, do their own advertising, choose their own customers, and keep all of the profit. And employees, who work for their employer for set hours, and get a stable salary and benefits in return.

We need a new third category: dependent contractor. Once that exists, we can start a more meaningful debate on what freedoms vs stability guarantees are best for it, without trying to force people into one extreme or the other.

> So deprecate it with a runtime warning and remove it after some years.

After the Python3 brouhaha, I think people are very cautious about making backwards incompatible changes to the language, even with a deprecation warning.

If it was done together with the rest of Python3 changes then it could have been approved, but not any more.

As Guido suggests, adding the warning to pylint and other style checkers, but keeping compatibility is much easier.

The IRS is probably the best US example of "proportionate punishments" and why people should not be overly afraid of GDPR.

The tax laws are vastly more complex than GDPR. The maximum penalties for tax fraud seem to be $250,000 + cost of prosecution + 5 years in jail.

If you make a small mistake on your taxes, and the IRS notices, you will probably receive a warning and have to repay it with interest. If you make a negligent mistake, you may be in addition be fined a small percentage, like 10-20%, of the amount you failed to declare. You have to conduct very large scale and intentional tax evasion for the maximum penalties to apply.

The IRS could argue for and try to apply the maximum penalties for a lemonade stand, but they don't. And people go on with their lives, put in their best effort to comply, and can be confident that they will be treated fairly.

> And then the salon and the restaurant start using Duplex as well, and all phone conversations become Google talking to Google.

This must be the most convoluted API protocol ever invented.

> One region is desert, only 10,000 people live there

> In the other region there are 1M people

This has already been normalized: these are European NUTS-2 regions, which are drawn to contain roughly equal populations. Each NUTS-2 region is supposed to be 800k to 3 million people per region. It's not perfect, but it's not just geographical borders with wildly different populations.

For example, London is split into 5 regions, most big cities are their own region, and small countries are just one region. Going into even smaller regions would be nice (and are defined in the standards as well), but it seems that nobody has put in the effort to collect data at that granularity.

> I really dislike this kind of visualization since it makes regions with total different population densities appear on the same level.

This visualization is using European NUTS-2 regions, which have roughly equal population. Each region is between 800k and 3 million people. While perfect scaling is not practically possible, it is much better than geographical regions.

You could skip the price models/curves, and just go with a real-time exchange. Something like NordPool (https://www.nordpoolspot.com/), which trades electricity between UK, Germany, Nordics and Baltics.

Electricity price on the market changes every hour depending on production and consumption. You can trade on it like on any futures market, or as an active participant if you had a large battery or transmission cables. Local utilities here offer "market price + 5% margin" plans to home consumers if you want to take advantage of the lows to adjust your usage.

XML parsers are necessarily over-complicated for structured data, because it is a text markup language, not a nested data structure language.

<address>123 Hello World Road, <postcode>12345</postcode>, CA</address>

is perfectly sensible XML. The address is not a tree structure or a key-value dictionary - it is free text with optional markup for some words.

You can use XML to represent nested data structures with lists and dictionaries, but the parsers and their public APIs must still handle the freeform text case as well.

Technically yes. But there just isn't enough potential energy in the water falling on a typical house.

For example, US average yearly rainfall of 76cm, on a 10m*15m roof, at height of two stories at 5 meters, would give you 1.5kWh of energy per year. That's enough to run the appliances in your home for an hour.

You might be in a more rainy location, or have a larger home, but the end result is still insignificantly small.

Following the recommended safety distance (2-3 seconds of travel distance if I recall correctly) is quite difficult in moderate to heavy traffic.

If you leave a large enough gap with the car in front, then people will merge into that gap. If you then slow down to create a new gap - people will overtake and merge in again. You end up travelling slower than the rest of traffic, with people overtaking and merging, which creates dangers in itself.

My impression is that "US taxes are complicated" arises from the fact that they have such a wide variety of possible tax deductions and tax credits, each with complicated conditions and rates. For medical expenses, moving expenses, training expenses, for various personal purchases that you use for work, for solar water heaters, and so on.

If you earned salary from one employer and used only a few standard deductions, then filing US taxes should be easy as well.

> Is the regulation state that we must guarantee right to erasure or that we must make a reasonable effort to erase customer data on request?

The regulation does not say that this has to be automatic or instant - but if the request to erase comes in, you must be able to somehow do it. If it means a person going through admin interfaces of all 34 SaaS tools, that's fine. But in the end you have to erase all of it, "it would take unreasonable effort" is not accepted as a reason to refuse or skip some third parties where the data has been sent.

If the SaaS products don't offer permanent deletion options, then you can't send personally identifiable data to them in the first place.

To a certain extent, they aren't.

The same compilers and tools are used for both, many developers mix the two in one codebase, and use small features from C++ in "C programs" because the compiler allows them to. For example before recent C standards, function overloading by argument types or declaring variables in the middle of a function.

But Python2 and Python3 are way more similar than C and C++.

BeautifulSoup4 is Python3 compatible. It was released under a new name.

uWSGI has Python3 support as a module.

I have been using both on Python3 for many years. I don't think there is any python module left which does not have Python3 support or a more modern, better alternative.

> it's like when you buy an appliance. You can buy the thing that meets the needs for $X, or you can buy something that's better for $2X. Of course, the better appliance would be better. Should we make a law that requires companies to only make the better one?

Maybe? Many such laws already exist: regulations on fire safety of buildings, fire safety of pillows and furniture, energy efficiency and safety of cars and home appliances, anything related to food processing, and so on.

I don't think there are any consumer products at all where governments haven't made laws about only selling "the better one".

If Tesla autopilot relies on good quality road markings, then it's not yet usable in 80% of the world.

The confusion here stems from the multiple meanings of the word "capital".

The logic is identical to for example founding a company in the UK: https://www.gov.uk/limited-company-formation/shareholders

You pick a "name value" and number of shares when founding, for example £1 x 500 shares. This is the "share capital", and official maximum liability of the founders for the company's debts. It also defines the smallest unit of ownership that can be assigned to a person. But of course the actual starting investment, assets, and the market value of the shares can be much higher.

Estonia doesn't use the concept of "number of shares out of total shares", but instead "euros of ownership out of total share capital". For a typical small business you would set it to 2500 EUR and can split ownership at 1/2500 granularity.

I think the confusion here might be "starting capital" vs "registered share capital". You should set the registered share capital to the minimum allowed 2500 eur. Even companies making hundreds of millions of euros in revenue set usually set it to 25000 eur. You can then invest any amount over that as your actual starting funds without increasing the registered share value.

That way the company is only required to own at least 2500 eur in assets, which should not be a problem for any serious business.

Three people in the back seat is a couple hundred kilos.

Modern cars, including the XC90 have a tilt sensor to adjust the headlights automatically for this.