cdavid

This is not done everywhere. I've never hired in the US, but worked for companies in Europe and JP, from <100 people companies to FAANG, and all of them opened dedicated listing for every position we had to fill.

The population rejected more autonomy with a large majority (>70 %) in the last referundum.

For once Cholesky is less general than QR: Cholesky only makes sense for positive matrices, while QR works for any matrix (including non square).

Also QR is a primitive for operations like finding eigenvalues, and I don't think Cholesky can be used there.

The author explicitly mentioned syncing to his parents house. Even the "RAID is not backup" should be more nuanced IMO once you are talking about FS that supports regular snapshots.

It is especially strange not to see it in the list given GiTS is heavily featured (according to the comments, I can't access the page or web archive ATM).

Patlabor movie 2 was directed by the same director as the original 1995 GiTS animation movie. Both patlabor 1 / 2 have similar themes to GiTS, and are heavily cyber punk in themes and esthetics.

The metaphor breaks quickly because as a first approximation the electricity "quality" does not depend on the provider, and will not change overtime. That's not true of LLM output.

For NumPy/Pytorch, the C API is much bigger issue than pickle. I have not looked at the architecture of this, but given it uses its own IR + replaces ref counting w/ a GC, I am assuming it does not have C API compatibility.

The same way cloud is about doing the exact opposite.

Understanding a bit of accounting / corporate finance opened my eyes to many things.

That's debatable. We can't go back in history, but if it were not for ML/data science, I believe python 3 would have killed python. At that time web dev / CLI utilities were major use cases, and that was the time golang became mainstream.

Data science, and then ofc DL being done through python just when python 3 was kinda usable (around 3.3/3.4) was a struck of luck timing-wise.

Also NI, etc. was very linked to the scene from the early days.

Cubase, etc. have no such link that I know how, but there was still the strong hacker culture around atari and to a lesser degree amiga (vs PC), when PC was just not usable for anything low latency in mid 90ies.

I wanted to understand the implementation of some numerical algorithms, and the tech reports were not enough.

I cloned the repo of said library, gave it claude and asked it to write a new technical report in math notation, but with annotation with link to the code so that I can pick up the details. It basically one shotted the full report and that helped me re-implement it in "pure python + numpy", "manually".

Partially a mix of strong, hacker culture in Germany in the 90ies + Berlin being a major place for electronic music in that decade.

For example, ableton was famousley co-created by the members of the monolake, a pioneer of minimalist techno in the 90ies. Some history there: https://www.roberthenke.com/interviews/ableton.html

no because it does not come from the same budget

Not really. GPU many cores, at least for fp32, gives you 2 to 4 order of magnitudes compared to high speed CPU.

The rest will be from "python float" (e.g. not from numpy) to C, which gives you already 2 to 3 order of magnitude difference, and then another 2 to 3 from plan C to optimized SIMD.

See e.g. https://github.com/Avafly/optimize-gemm for how you can get 2 to 3 order of magnitude just from C.

scilab is not based on numpy/etc. However, matlab was certainly an inspiration for the scientific python stack in early 2000s. I myself started contributing to numpy and matplotlib by adding missing features I needed to move away from matlab in 2006 or so.

A fifth edition has been out recently: https://shop.elsevier.com/books/programming-massively-parall...

I started learning about GPU and CUDA from this book recently, and I agree the writing is confusing, and code examples have errors. However, it is still a nice reference about many types of algorithms for heterogeneous memory devices, it helped me understand better some patterns for CPUs.

Did not know of the "thinkism" expression. When I was studying in France eng. school, I called that "the mythe du cerveau" (literaly "the brain myth", though does not roll on your tongue as well).

It is guaranteed failure mode of large orgs. Curious to hear about more references on how to fight this at an organization level, besides the one given in the OT.

The main point of mythical man month was that communication cost across people was the main cost as project grow in complexity.

So increasing individual output by itself is not enough to affect the argument. It could, if you also reduce the size of people needed for a project, where people are everyone included in the project, not just SWE. But there are strong forces in large orgs to pull toward larger project sizes: budgeting overhead and other similar large orgs optimize for legibility kind of arguments.

IMO the only way this will change is when new companies will challenge existing big guys. I think AI will help achieve this (e.g. agentic e-commerce challenging the existing players), but it will take time.

fair, somebody else clarified already !

Indeed. I would add a third factor to compute and datasets: the lego-like aspect of NN that enabled scalable OSS DL frameworks.

I did some ML in mid 2000s, and it was a PITA to reuse other people code (when available at all). You had some well known libraries for SVM, for HMM you had to use HTK that had a weird license, and otherwise looking at experiments required you to reimplement stuff yourself.

Late 2000s had a lot of practical innovation that democratized ML: theano and then tf/keras/pytorch for DL, scikit learn for ML, etc. That ended up being important because you need a lot of tricks to make this work on top of "textbook" implementation. E.g. if you implement EM algo for GMM, you need to do it in the log space to avoid underflow, DL as well (gorot and co initialization, etc.).

Also one of the initial creator of haproxy, a well known reverse proxy. To imply somebody like as a simple "AI shill" is just ignorant.

I agree. It is difficult to convince leadership to do this work at all ("it works on my example, ship it"), and in my experience most DS don't even want to do it.

One of the key value is that it forces some thinking about what is the task you want to solve in the first place. In many cases, it is difficult if not impossible to do it, which implies the underlying product should not be built at all. But nobody wants to hear that.

Doing eval only makes sense if making the product better impacts something the business cares about, which is very difficult to do in practice.

The typical solution is to work in one of the "global" (aka American) companies in Japan: google, amz, apple, ms, etc. At least for now there are enough jobs across all those companies for motivated foreigners, though that could change.

Yes, this is the real cause, and the OP explanation is just a symptom of that.

My rule of thumb is that management complexity is given by #direct reports x #project, where project is defined as a set of stakeholders (be it PM, etc. depending on business).

Concretely, managing 12 ICs on a well defined platform team w/ a single PM is much easier than managing 6 people working across 6 businesses, as is more common when managing a team of data scientists.

I can believe it is deliberate at the top, I've certainly seen first hand in several orgs I've worked at.

My sense is that unless actively managed against, any org big enough to have a financial department and financial planning will work under assumption of fungibility.

You had to accept some license terms before you could download the VST SDK. When linux audio started to get "serious" 20 years ago, it was a commonly discussed pain point.

Concretely, it made distributing OSS VST plugins a pain. Especially for Linux which generally will want to build their packages.

I agree the big deal is tool calling.

But MCP has at least 2 advantages over cli tools

- Tool calling LLM combined w/ structured output is easier to implement as MCP than CLI for complex interactions IMO.

- It is more natural to hold state between tool calls in an MCP server than with a CLI.

When I read the OT, I initially wondered if I indeed bought into the hype. But then I realized that the small demo I built recently to learn about MCP (https://github.com/cournape/text2synth) would have been more difficult to build as a cli. And I think the demo is representative of neat usages of MCP.

Since the OT is about EU, it is important to keep in mind that costs per MW are much lower in EU than in the US (or the UK).

E.g. according to https://www.samdumitriu.com/p/infrastructure-costs-nuclear-e..., UK/US is ~10 millions GBP, France ~4.5, and China/Korea/Japan around 2.5.

I don't know much about nuclear plan, but I doubt UK are much safer in practice than French ones, or even Korean/Japanese ones. I suspect most of the cost difference across countries of similar development to be mostly regulation. And it is a nice example that sometimes EU can be better than the US at regulations :) (I don't know how much nuclear-related regulations are EU vs nation-based though).

It is not cheap, but it is clearly made by people who care about music. In those days where "slop" is so common, for people who can afford it, it is a nice refresher.

Another minor inconvenience is that it is memory hungry for large libraries. In my case, for ~1 TB of flac, the docker takes 5-6 GB RAM on my debian NAS. Limiting it at 4 GB definitely crashed w/ OOM, at 8Gb never had issue.