You can buy a ULEZ-compliant car for under £1000 - less than the cost of a year's insurance in most London boroughs. If you can't afford to buy a car that is only 18 years old, then I might suggest that you can't afford to own a car at all.
I agree with you. The idea that ULEZ means people must give up driving is ridiculous and overblown. It does not affect the vast majority of people at all.
Apps like Auth are a great fit for Flutter, where desktop support is nice to have. We're also using Flutter for our Photos[1] app, and it has served us well so far. Wherever necessary (cryptography, ML, transcoding, ...), we use a bridge to communicate with the native layer, and Flutter becomes a presentation layer of sorts.
Reg. Gmail marking our verification emails going to spam, we aren't sure what the issue is. We migrated from Zoho to SES recently hoping to fix this, but that has not helped. If anyone here understands email deliverability, please do share your thoughts, we'd be grateful!
We've a migration guide from Authy here[2]. They make it difficult, but it's possible.
[1]: https://ente.io
I’ve tried the app a few times over the last couple of years and had a dislike of the UI because it did not _feel_ right, like it was slow or something. I can’t say exactly what.
It is almost certainly because it is using flutter rather than native DOM elements.
(I’ve been keeping track of ente but never quite made the jump - not solely due to the UI though!)
Not something so complex that it requires docker. Not something that requires you to install a separate database. Not something that depends on redis and other external services.
I’ve turned down many self-hosted options due to the complexity of the setup and maintenance.
I find a files-centric (and more broadly filesystem-centric) approach easier to grapple with than one that focuses on apps (and hiding away the data). It makes it much easier to access my own data for other purposes outside of what the app provides. In particular when the files are in plain-text or otherwise human-editable. I can reuse all of the existing tool that I'm familiar with to search, modify or re-purpose the data.
1. More likely to be red because the urn has a greater chance of having more red balls
2. Equally likely by considering all remaining urn possibilities to be equally likely
3. More likely to be green because obviously there is one less red ball than before
I wrote a Python program to simulate the problem. It tells me that the correct answer is (2) - it's equally likely that the next ball is red or green.
I wonder if I've made a mistake, or if that's really the real answer!
#!/usr/bin/python
import random
from collections import Counter
def experiment():
urn = random.choices(["R", "G"], k=100)
if urn.pop() != "R":
return
return urn.pop()
results = (experiment() for i in range(1_000_000))
results = (result for result in results if result is not None)
print(Counter(results))
EDIT: I did make a mistake! The above produces a binomial distribution of urns with red/green. As in, the most common urn is one with an equal number of reds and greens, and the least common is all reds or all greens. Whereas they should have equal probability. To actually match the question: #!/usr/bin/python
import random
from collections import Counter
def experiment():
num_red = random.randint(1, 100)
num_green = 100 - num_red
urn = ["R"] * num_red + ["G"] * num_green
random.shuffle(urn)
if urn.pop() != "R":
return
return urn.pop()
results = (experiment() for i in range(1_000_000))
results = (result for result in results if result is not None)
print(Counter(results))
The answer is indeed (1) More likely to be red.Upgrading from cloud run to use proper vms was very easy because vms can be booted with a docker container as one of the arguments. It will just go off and run that with a default OS. Running docker containers in gcloud is super easy.
And scaling that is easy too. Basically you define an instance template that defines vm details; including the docker container url. And then you update your instance group with that template and all the instances are replaced one by one. You use the instance group as a service for your load balancer and with the right health checks configured this basically gives you zero down time deployments, auto scaling, etc. If there's an issue starting the container, it just aborts the restart and continues running the old containers.
The closest thing in AWS would be ECS but it's a lot more hassle to setup.
One great feature in gcloud is "copy this screen/dialog/whatever as a gcloud command". That made scripting the above super easy. We use github actions for all this. For each service, we use 1 command to update the template and 1 command to deploy it.
- Congestion charge, which applies to everyone, except residents, driving in the centre of London during weekdays
- Low Emissions Zone charge, which applies to everyone driving a vehicles older than emissions class Euro 5 (2009) inside nearly all of London
- Ultra Low Emissions Zone charge, which applies to everyone driving a vehicle older than emissions class Euro 6 (2015) inside the centre of London
And to make things even more fun: If you do not have automatic billing setup you are required to pay online on the day you trigger the fee. If you are even a day late, you will face penalties of hundreds or thousands of pounds, depending on your vehicle class.
The ULEZ standard requires diesel cars to conform to Euro 6, available since 2015 - the diesel emissions scandal notwithstanding. (The in-practice standards for diesel cars are much much more lenient than for petrol cars.)
The ULEZ standard requires petrol cars to conform to only Euro 4, required since 2005 but some cars manufactured as early as 2001 meet the standard including my 2002 MINI.
This means relatively few people are actually affected by ULEZ, compared to the implication that you need a car manufactured from 2015 onwards.
It’s a common Japanese food and he just said give it a go.
Arch is bleeding edge yet permanently issue prone, Debian is stable and conservative/slow in updating?
Seems odd to jump from one end of the spectrum to another (I use Debian and Mint mostly but have respect for the Arch project’s aims)