This is part 5 of a series.

1. “1974 ” on the traditional Unix Filesystem.
2. “1984 ” on the BSD Fast File System.
3. “1994 ” on SGI XFS.
4. “Vnodes ” on how to have multiple filesystems in Unix.

Progress is sometimes hard to see, especially when you have been part of it or otherwise lived through it. Often, it is easier to see by comparing modern educational material and the problems discussed with older material. Or look for the research papers and sources that fueled the change. So this is what we do.

This is part 4 of a series.

1. “1974 ” on the traditional Unix Filesystem.
2. “1984 ” on the BSD Fast File System.
3. “1994 ” on SGI XFS.

Progress is sometimes hard to see, especially when you have been part of it or otherwise lived through it. Often, it is easier to see by comparing modern educational material and the problems discussed with older material. Or look for the research papers and sources that fueled the change. So this is what we do.

This is part 3 of a series. The first part is “1974 ”. The second part is “1984 ”.

Progress is sometimes hard to see, especially when you have been part of it or otherwise lived through it. Often, it is easier to see if you compare modern educational material, and the problems discussed with older material. And then look for the research papers and sources that fueled the change.

Electrive.net had an article about Copenhagen banning combustion engines in the city, starting 2030: (Article in German ). So I had to check what is the current state in Amsterdam.

Current state

The Netherlands has a central register for license plates. It is public, and anyone can check. There are many places that allow you to do that for car, not owner data. For example .

The city of Amsterdam also allows you to check if a given license plate is allowed to enter the cities milieuzone. You can check yourself . And so can any license plate scanner.

“Computers are simple” is what I am telling people I train. “There are only Zeroes and Ones, and it is not getting much more complicated.”

“But computers are hard”, they respond.

“That is correct. In computer systems, complexity is almost never in the individual layers, but it comes from the width and breadth of the stack. It’s in the interactions of the components that we are putting together.”

When you start with how a CPU is being built, and then put the layers of the stack on top of each other until you end up with a classical single-process application, in some object-oriented language, with a GUI – that’s around two to three dozen layers of abstractions piled on top of each other. Things that one could learn the internals of, and how they interact. But that’s only local, without network stacks, communication protocols, proxies, and without the peculiarities of distributed systems, which open up the same exercise, again, only across, not down.

This is part 2 of a series. The first part is “1974 ”.

Progress is sometimes hard to see, especially when you have been part of it or otherwise lived through it. Often, it is easier to see if you compare modern educational material, and the problems discussed with older material. And then look for the research papers and sources that fueled the change.

In Linux (and Unix in general), this is easy.

Progress is sometimes hard to see, especially when you have been part of it or otherwise lived through it. Often, it is easier to see if you compare modern educational material, and the problems discussed with older material. And then look for the research papers and sources that fueled the change.

In Linux (and Unix in general), this is easy.

1974 - Unix V7 File System

We find the Unix Version 7 Research Release in Diomidis Spinellis unix-history-repo . If we are reading The Design of the Unix Operating System by Maurice J. Bach , we would want to look at the Research V7 Snapshot branch of that Repository.

Back in October last year, I had been speaking to a few long-time friends at SeveralNines for a podcast. The recording is now out, and you can listen to it at this location or in the Podcast Player of your choice.

• Booking.com, Part 1 - Running data infrastructure at an Enterprise scale

• Booking.com, Part 2 - How Booking.com built their own Sovereign DBaaS at scale

Based on a discussion on IRC and Mastodon: “How can I get access to the return values of my (Python-) programs functions?” And more generally, how can I trace function execution in Python, showing function parameters and return values?

PyCharm builtin method

Of course, you can always simply turn on this in the PyCharm debugger:

PyCharm, Debug Window, Gear Icon, “Show Return Values”

Do it yourself: sys.settrace()

(via Peterkelly ): Python has a built-in API for tracing: sys.settrace() .

Given a table named tbl with one million entries, we want to select a random row from this table, fast. Our table definition looks like this:

create table tbl (
    id INTEGER NOT NULL,
    d VARCHAR(200) NOT NULL,
    INDEX(id)
);

Dense id space

We can generate some test data using a recursive CTE:

mysql> set cte_max_recursion_depth = 100000;
mysql> insert into tbl 
    -> with recursive c(n, u) as (
    ->   select 1, uuid() 
    -> union all
    ->   select n+1, uuid() from c where n < 100000
    -> ) select * from c ;

The Recursive CTE will generate 100k pairs of (number, uuid()). The initial row is defined in the upper row of the UNION, each subsequent row builds recursively on top of that, by simply counting up.