pg314

I did that with Git itself. As a bonus you’ll learn more about a tool you’re probably using everyday. If I remember correctly, even the early commits were pretty high quality.

The 2018 ISO standard [1] is 520 pages. Not what I would consider small. Nor is it simple. The integer promotion rules and undefined behaviours will trip up even experienced C programmers.

Something like R5RS for Scheme (50 pages or so) is what I think of when I hear small and simple.

[1] https://www.iso.org/standard/74528.html

Thankfully your attitude wasn't prevalent in previous generations or polio and smallpox would still be rampant.

You’re right. I misinterpreted ‘record usage’. I found a 2013 blog post [1] claiming a 143 thousand tweets per second peak.

[1] https://blog.twitter.com/engineering/en_us/a/2013/new-tweets...

Musk claimed a record of 20,000 of tweets per second recently [1]. How does that square with what you’re saying? 300 times 450 is closer to 150,000. Am I missing something?

[1]https://twitter.com/elonmusk/status/1595505413113323520?s=20...

>From the guy who managed to launch Starlink and currently runs the most successful/effective space launch provider,

He is not running SpaceX, Gwynne Shotwell is. He’s just the part-time CEO, very adept at self-promoting.

According to Wikipedia [1], Gordon Pirie ran 347,600 km in the 40 years to 1981. He lived another 10 years after that, so he might have come close. The distance to the moon is 384,400 km.

[1] https://en.m.wikipedia.org/wiki/Gordon_Pirie

In 1999, to obtain the participation of the greens in the government, the other parties agreed to the closing of nuclear reactors after 40 years of operation [1]. 2022 seemed like a long time away at the time, especially in politics.

In 2012, small cracks were discovered in the pressure vessels of a number of reactors, introduced by hydrogen during the casting of the steel. That was grist on the mill of the anti-nuclear lobby. According to the expert reports, the vessels should be ok (there are some links to English reports on the nuclear safety agency website [2]), but it is easy to fear-monger when nuclear energy is involved. That seemed to have sealed the fate of the nuclear reactors.

[1] https://en.wikipedia.org/wiki/Nuclear_power_phase-out#Belgiu... [2] https://fanc.fgov.be/nl/dossiers/kerncentrales-belgie/actual...

Even if you have nothing to hide, others do. You don’t want somebody to be able to blackmail a politician or a judge who e.g. had an affair.

Family of four here, all groceries done with a cargo bike, year round. And I’m definitely not the only one where I live. You can wear warmer clothes if it’s cold, the bike has lights (and there are street lights) for when it’s dark, and a raincoat and rain cover for the bike work well against the rain. Definitely more fun and healthier than a car.

The initial number of 1 square kilometer of PV panels produced per year doesn't pass the sniff test. An average home installation is already 10 square meters, and a lot more than 100,000 installations are added in a year.

The global production of solar panels was 180 GW in 2020. Assuming around 200 W per square meter, you get 1 billion square meters of solar panels. So their initial number is off by a factor of 1000.

> but has imposed huge and everyday annoyances on everyone

Not on everyone. I can't remember the last time I used a straw, I manage to drink from a glass or a cup just fine. Is it really a huge annoyance for you? I understand that for some people (e.g. people with Parkinson's or a broken jaw) straws are a necessity, but most people should be able to manage just fine without them.

It's true that there are bigger contributors to plastic pollution, but it's hard to argue that plastic straws in the oceans or nature are a good thing.

> Exactly, and you need rolling resistance for traction.

No, you don’t. Look at e.g. gears: almost no friction, perfect traction.

> Which is why you don't ship hay on trains

No. You don’t ship it on trains because that is uneconomic. You keep your cattle close to your hay producing fields, where they can also graze.

Also, by your reasoning, an empty train would not be able to move?

> The train itself has to be heavier than the load just to stay on the tracks.

Why would that be? A typical 110 ton capacity freight train car weighs 33 tons unloaded. It has no problems staying on the tracks.

Besides both buses and planes typically weigh much more than their freight (and planes need to lift all that weight 10km vertically), so I fail to see how that is an argument against trains.

According to the Brussels Institute of Statistics and Analysis [1], in 2017, 34% of all commuters in Brussels commuted by train versus 36.2% by car. It might not make sense to you, but it does to other people.

[1] page 30 of https://bisa.brussels/sites/default/files/publication/docume...

You can find a ticket from Madrid to Paris taking 10.5 hours for 226 EUR.

It reminds me of the drawings by John E. Weaver from the thirties [1]. They were made by painstakingly digging a deep trench to study and sketch the roots. They did it multiple times for each crop to get a sense of how they develop in time.

[1]https://www.motherearthnews.com/organic-gardening/root-devel...

Covid-19 doesn't kill rapidly, so there is no pressure for it to mutate to become milder.

AAPL is 40%+ of BRK's investment portfolio. There is a substantial number of wholly owned subsidiaries. AAPL constitutes only about 25% of BRK's market cap.

True. I missed that. The calculator at [1] gives totally different returns with dividends reinvested, though: 7.6%.

[1] https://dqydj.com/dow-jones-return-calculator/

That ignores dividends. That will add a couple of percentage points to the return.

If I rerun the calculation from the cherry-picked peak of about 360 in 1928, I get around 4.5% after inflation, without dividends.

What are the laws of physics that would be broken in this case?

Months-old Chrome tabs are not resident in RAM.

That is incorrect. An Emacs obarray is a kind of hash table [1].

[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Cr...

The Economist.

> This feature is the sort of thing that a clever person will use as a shortcut to actually writing robust ETL code.

With mysql_fdw you can write the ETL code itself in PostgreSQL: you expose (a subset of) the MySQL tables through the FDW, and then you write SQL code to transform it and copy it to your analytics tables. That's exactly what I did in one project: at night the whole analytics database was recreated in 15 minutes or so (the biggest table had about a hundred million of rows).

Most of the caveats don't apply in that case:

> 1/ Strict upper bound on how much data it can pull in.

I don't know what you mean by that. As far as I know, there are no such bounds.

> 2/ MySQL migrations need to be run on both Postgres and MySQL

Since the analytics database is recreated every night, that is not the case.

> 3/ No way to gracefully migrate or version

Same as 2.

> 4/ MySQL’s “loose” typing doesn’t play well with Postgres’s “strict” typing. This means data can break the fdw.

I never ran into that, but it is possible.

> 5/ Pain in the ass to debug.

Much easier to debug than ETL scripts that talk to two different databases, in my opinion. You can interactively write the SQL code in psql. I used pgTap to unit test the SQL code.

> 6/ This is debatable, but I don’t believe that application code (SQL code in this case) should live in the database.

I don't see any problem with that.

> 7/ Postgres and MySQL have different performance characteristics. This can lead to hard-to-debug performance problems if you are explicitly or implicitly using a fdw in your query.

In my approach you just do a 'SELECT * FROM x' on the mysql side. All performance problems are easily debugged on the postgres side.

> 8/ If you want to keep a local copy of MySQL data in Postgres (to solve for #7) you then have to write code to keep it up to date. This defeats the convenience of the fdw.

If you recreate the analytics database periodically this is a non-issue.

> 9/ At least when I was using fdws, they didn’t have predicate pushdown. This causes you to do structure queries in a weird way to get filters to work as you expect.

PostgreSQL has had predicate pushdown for years now.

> 10/ You have to manage schema type mismatch between MySQL and Postgres. This isn’t fun or productive work.

You have to do that anyway, even if you're using ETL scripts.

If you use the FDW, you can implicitly create the tables on the postgres side: CREATE TABLE my_analytics_table AS SELECT foo, bar FROM mysql_fdw_table WHERE ...;

That way my_analytics_table will get the postgresql types corresponding to the mysql_table. If anything changes, it gets automatically propagated. Analytics queries against my_analytics_table might break, though. Usually, when it's a change from e.g. int8 to int16, things will continue working.

> It could get absurd, but the moment you let the government control even something small, it just keeps growing until we are quite literally Nazi germany where only “ideal” people are allowed to breed or receive permission to open businesses or get desirable jobs.

You are making a non-sensical slippery slope argument. Heroin has been prohibited for a long time in the US, yet it hasn't turned into Nazi Germany.

> A CO2 tax can't work unless it was implemented globally INCLUDING developing countries. (Which is a non-starter of course.) Because otherwise people will just ship industry and manufacturing elsewhere.

Manufacturing only accounts for 20% of fossil fuel CO2 emissions.

Have you looked into using something like SQLite instead of the filesystem? [1]

[1] https://www.sqlite.org/fasterthanfs.html

> Regular distance running is punishing on your joints, even if you're a forefoot runner with perfect form.

The studies I'm aware of (e.g. [1]) point in the opposite direction: runners have a lower risk of osteoarthritis, potentially because they have a lower BMI. As an avid long distance runner myself, if you have any evidence to the contrary, I'd be very interested to read it.

[1] https://www.ncbi.nlm.nih.gov/pubmed/23377837