zzbn00

Yes, they buy these chips from fabs (made to their design) but it is the chips they then sell on, at about a 4x markup to what they bought them for. Good business model! Buy low, sell high. Whether good enough to justify current valuation is another question.

There is also the problem of thinking and problem solving at altitude -- we are much worse at it at high elevation compared to at normal elevations!

Very nice.

In my experience much of the complexity of numerical software is to enable the search for the algorithm that works well with the problem/data you have. Once you know the exact algorithm you want, it is possible to make a nice clean minimalistic implementation, but that does not mean such an implementation would have been easy at the beginning.

12 bits/word

60 words/minute

60 minutes/hour

8 hours/day

5 days/week

4 weeks/month

=> 7 Megabits => 864kBytes . Fits onto a floppy.

What we could express as words, we could fit onto floppies.

NiX (and I assume Guix) are very convenient for this as it is fairly easy to turn frame pointers on or off for parts or whole of the system.

The documentation mentions GNU stow:

https://www.gnu.org/software/stow/manual/stow.html

This was very useful in early 2000s running shared linux machines with a diverse set of software for scientific applications.

For the Map Reduce specifically the one of the big issues was the speed at which you could read data from a HDD and transfer across the network. The MapReduce paper benchmarks were done with computers with 160 GB HDDs (so 3x smaller than typical NVMe SSD today) which had sequential read of maybe 40MB/s (100x smaller than a NVMe Drive today!) and random reads of <1MB/s (also very much smaller than a NVMe Drive today).

On the other hand they had 2GHz Xeon CPUs!

Table 1 in the paper suggests that average read throughput per worker for typical jobs was around 1MB/s.

Horizontal scaling did have specific incentives when Map Reduce got going and today also in the right parameter space.

For example, I think Dean & Ghemawat reasonably describe what were their incentives: saving capital by reusing an already distributed set of machines while conserving network bandwidth. In table 1 they write average job duration was around 10 minutes involving 150 computers and that on average 1.2 workers died per such job!

The computers had 2-4 GiB memory, 100megabit ethernet and ISA HDDs. In 2003 when they got map reduce going Google's total R&D budget was $90million. There was no cloud so if you wanted a large machine you had to pay up front.

What they did with Map Reduce is a great achievement.

But I would advise against scaling horizontally right from the start because we may need to scale horizontally at some time in future. If it will fit on one machine, do it on one.

This was nicely foreseen in the original Map - Reduce paper, where the authors write:

  > The issues of how to parallelize the computation, distribute the data, and 
  > handle failures conspire to obscure the original simple computation with large 
  > amounts of complex code to deal with these issues. As a reaction to this 
  > complexity,we designed anew abstraction that allows us to express the simple 
  > computations we were trying to perform but hides the messy details of 
  > parallelization, fault-tolerance, data distribution and load balancing in 
  > a library .

If you are not meeting this complexity (and today with 16 TB of RAM and 192 cores, many jobs don't) then Map-Reduce / Hadoop is not for you...

They do, but applications on these matters can easily overwhelm the financially weaker opponent. Interesting comment in one of the Post Office judgements:

"10. Finally, disclosure is very expensive. The court will be astute to guard against it becoming either satellite litigation or a weapon in the interlocutory arsenal."

https://www.bailii.org/ew/cases/EWHC/QB/2019/3408.html

Private prosecutions like this are specific to England & Wales (Scotland has a separate legal system where I believe they are extremely rare; Northern Ireland is also a separate legal system).

While the incentives are not to reveal evidence the law is absolutely clear that all evidence identified must be revealed. The difficulty is that forcing and unlimited discovery to identify the evidence would break the whole legal system, and this is what parties can hide behind (for a while at least). We'll have to see when and how anybody will face the consequences of any failures to reveal the evidence.

I very much recommend reading the Judgements in Bates vs Post Office. As litigation progressed you can notice how it becomes apparent to the judge how Post Office legal tactics and behaviour undermined the prosecutions.

The slowness of Python meant that nobody thought "it'll be easier just to write this routine" as opposed to looking to re-use existing (most often compiled) code. And if you are doing science, the less time you spend re-inventing code, the more science you will get done.

The editorial is a little indirect but the funding challenge is the key bit.

What the editorial is saying is that both the currently private projects in US to build the new generation of ground telescopes need government money to be completed but it is unrealistic for government to fund both. Therefore the government should pick one to take over and then make sure it has enough money to be built.

"The course is turned into a game of skill, where manipulative ability outweighs understanding"

Nicely written. But isn't a corollary that we should stop exams in Maths (and Physics/etc/etc) degrees and just teach people who want to learn, how much they want to learn?

Exams are for people designing bridges and doing surgery. Basic science just learn and start doing some to see if it is for you.

This is one of the reasons why Python got so popular.

It is too slow to reimplement big pieces of software in it, so people just used bindings to existing code. And productivity rocketed!

Right, in principle they are better than just motion sensing since they can also detect breathing (and even heart beating!). And with modules costing 1-2$ people think... why not?

I've worked with a few people who started their careers on punch cards. I learnt:

- Do not write a program if it does not need to be written

- Think about what you are doing before you do it

- Write with care and attention (whether code or prose)

Seems as applicable today as it was then.

It will I'm afraid going to be a difficult battle to win, e.g.,

- modern iPhones can communicate with global satellite constellations (https://support.apple.com/en-us/HT213885). I imagine this will grow substantially

- Even bike lights nowdays have radar built into them (e.g., https://www.garmin.com/en-GB/p/698001). Also room presence sensors are beginning to use radar 22GHz.

We can now build incredibly cheap and lightweight radio devices up to 80 GHz. They will inevitably be used more on the ground, in air and on satellites as the economics makes new types of uses practical.

They are modular but not very interchangable (there are 133 different designs of the segments in the primary mirror).

Making a much larger mirror would also face another obstacle: the focal length is designed to be practical for a ~40m mirror.

Just yesterday had occasion to use a battered old blackberry passport with physical keyboard. To me undoubtedly superior for text input compared to current devices.

The wikipedia article has a link to an accident investigation report where unfortunately it was not put back onto the craft after maintenance.

p4d.24xlarge spot price is $8.2 / hour in US East 1 at the moment...

My vague memory is that there was/is a military or government site nearby which is why the research centre is also there.

Can report Jülich is not near Munich.... Anyway will be fascinating to see how the SiPearl chip works out.

I meant the solictor of the Post Office -- solicitors in England are both classified as officers of the court and owe duties to the Court. So amongst other things Post Office's own solicitors should have declined to act in any way that could mislead the court.

This seems like an FFT based benchmark.... I believe NumPy for licensing reasons includes a port of old FFTPACK which is only single threaded. (Py)FFTW or others are surely much faster.

So the test seems to compare one thread of a CPU launched in 2016 running a port of 40year old fortran code to a optimised FFT library on a GPU launched in 2020.

In principle there was already some separation of duty as solictors in England owe a duty to the Court regardless of who pays them. However it seems not to have been enough in this case. Hopefully will be looked into.

Washing the salt off will reduce rate of corrosion. Probably the most important to wash is the underneath. I suppose it is more important for cars that do not do that many miles/year as in this case the internal parts will last a long time.

Very nicely written article.

One thing about rust, salt and moisture: salts deliquescence. I.e. they absorb moisture from air until there is enough liquid to dissolve themselves in. This happens below 100% relative humidity (around 75% for common salt, but as little as 31% for cacl2). So salt-contaminated surfaces can easily get wet even when the air is not that humid, bad news for steel!