While BGP routers need to know route for every prefix, they can then can compress the routing table, by merging prefixes which have the same routing.
The problem is that the IPv4 address space is too fragmented to allow much compression.

IPv6 address allocations should allow for less fragmentation and better compression.

Interesting. I sounds a bit like an application I have.
Like yours, it involves UDP and Python.
I have 150.000 "jobs" per second arriving in UDP packets. "Job" data can be between 10 and 1400 bytes and as many "jobs" are packed into each UDP packet as possible.

I use Python because, intermixed with the high performance job processing, I also mix slow but complex control sequences (and I'd rather cut my wrists than move all that to C/C++).
But to achieve good performance, I had to reduce Python's contribution to the critical path as much as possible and offload to C++.

My architecture has 3 processes, which communicate through shared memory and FIFOs.
The shared memory is divided into fixed size blocks, each big enough to contain the information for a maximum size jobs.

Processs A is C++ and has two threads.
Thread A1 receives the UDP packets, decodes the contents, writes the decoded job into a shared memory block and stores the block index number into a queue.
Thread A2 handles communication with process B. This communication consists mainly of sending process B block index numbers (telling B where to get job data) and receiving block index numbers back from process B (telling A that the block can be re-used).

Process B is a single threaded Python.
When in the critical loop, it's main job is to forward block index numbers from process A to process C and from process C back to process A.
(It also does some status checks and control functions, which is why it's in the middle).
In order to keep the overhead low, the block index numbers are passed in batches of 128 to 1024 (each block index number corresponding to a job).

Process C is, again, multi-threaded C++.
The main thread takes the data from the shared memory, returns the block index numbers to process B and pushes the jobs through a sequence of processing modules, in batches of many jobs.
Withing each processing module, the module hands out the batch of jobs to a thread pool and back, while preserving the order.

It's actually pretty natural.
Usually, standards aren't created in a void. Before a standard can be written and agreed, someone has two design, test, maybe deploy real stuff.
More often than not, different teams will explore different avenues of research. And once they have invested, nobody wants to throw away their work and move to someone else's spec.
On the other hand, this often takes multiple iterations to reach a good standard

If you look at it...
CHADEMO has been around since 2010 and for a while, it was the only real solution.
But Tesla didn't like it, probably because of licensing terms, bulkiness and limited power (62.5 kW max), so they created their own for the Model S.
Other manufacturers and other players did not like it, for similar reasons. And Tesla's solution was proprietary.
So they went ahead and created yet another standard.

Finally, Tesla has decided to play nice.

Model S' battery has both more capacity and the ability to supply and absorb more power.

I think for a given technology, battery capacity and power (both in and out) tend to be related.

By assign, I mean giving them an address.
Whether it's by static configuration, stateless auto-configuration or DHCP.

Yes and no.

Yes, you'll need to assign every one of your machines an address which is based on the prefix assigned to you by your ISP.
In the absence of NAT66, your computers will need these addresses to access the internet.

No, you can additionally assign your machines an address based on a unique local address prefix.
You should to use a randomly generated ULA prefix to avoid future conflicts (eg, you need to establish a VPN to another network also using ULA).
But otherwise, it's legal to use a trivial prefix (FD00:whatever).

As usual, an interesting article with a terrible Slashdot title, overplaying the aspect of analog vs digital.

In fact, it's a lot more a matter of discrete vs integrated.

Decades ago, people designed and built digital logic, entire digital computers even, based on discrete (individual) valves or transistors.
Then, we moved to designing them based on many small integrated circuits which performed simple logic functions, like the 7400 series TTL circuits.
And then we moved to highly integrated digital circuits.
I've used micro-processors, field programmable gate arrays and even designed custom ASICs. But outside school, I never used a 7400 chip, much less design an AND gate based on discrete BJT transistors.
It's all digital, but it's different skill sets.

A similar change of skills happens for analog designers.
Some things that 20 years ago were done by a circuit on a board using discrete transistors are now done inside an integrated circuit.
Again, it's all analog but it's different skill sets.
(Some others, have moved from fully analog to mixed signal, digitizing analog signals and then processing them digitally).

Analog skills are still much needed.
Nowadays, the highly integrated digital circuits communicate between themselves at multi-gigabit speeds and our board designs face issues that, 20 years ago, were a concern only for RF analog engineers

But the needed analog skills are changing.
For example, when designing integrated circuits, it's increasingly necessary to be aware of the physical issues that happen at the sub-micron scale.
Being able to design a RF amplifier based on discrete HBT does not necessarily prepare you do design one in a sub-micron integrated circuit.

Not any more than ext4.

ext3 was an odd ball. It defaulted to a behavior where creating a file, writing into it and then renaming over into another file would _guarantee_ that after a crash you'd either get the old file or the new file.
XFS (and AFAIK all the other Linux journaled file systems) implemented did not provide such guarantees unless the application used an fsync/fdatasync before the rename.

However, since a) ext3 was popular and b) fsync could be pathologically slow on ext3, many applications became reliant on ext3's behaviour.
The net result was that, for other filesystems, after a crash users would be faced with files full of zeros.
It became a widespread problem when ext4 became the default, as it used much of the same policy of XFS. http://lwn.net/Articles/322823/

Meanwhile, this has mostly been fixed.
Partially, because ext4's widespread usage, applications began to use fsync properly again.
Partially, XFS and ext4 developers patched the filesystem to, under some circumstances, emulate ext3's behavior.

There are three competing DC charging standards in North America:
- The widely deployed Chademo (= 62.5 kW), backed by Japanese automakers mostly
- The upcoming, not yet deployed, CCS (= 90 kW), backed by SAE, a large number of western automakers and, increasingly, by
- Tesla's Supercharger ( = 120 kW?), which is used only by Tesla.

This is, of course, a f**king mess, which could undermine the efforts to build comprehensive charging networks.
However, it's a manageable mess.
While high power DC charging stations are expensive, having them support multiple standards adds little to the cost (5% per standard or less).
The competition between Chademo and SAE CCS looks like it will be resolved this way: AFAIK, pretty much any new DC charging station deployments looks to be dual standard.

Tesla was basically being left out. While they have built a very interesting network and they have a superior specification, they can't expect to cover all of North America with their own charging stations, while the rest of the world is using combined Chademo/CCS station.

Opening up their specification is a necessary step for them to play along with the rest of the world.

Bombs, even precision GPS or laser guided ones, are much cheaper than missiles. And a B-52 can carry a lot of them.
As a platform for loitering around an area and dropping precision weapons as requested, it should be the most cost effective platform USAF has.
And the option of carpet bombing is occasionally useful too.

First, my comment wasn't generally about whether C or Fortran is better.
I just just illustrating that C's aliasing isn't as much as an obstacle for vectorization as it's often said (and I probably said so in the past, so I'm also guilty).
In general, Fortran arrays and slicing map to pretty trivial C code. Most people can write decent stuff for that. Getting it to vectorize isn't hard.

Secondly, AFAIK, arrays and array slices in Fortran need to be used with a bit of care.
In some situations it can lead the compiler to copy the data into a temporary array (eg, passing a slice as a function parameter).
Another issue is that in a array with 2 or more coordinates, only one coordinate has a memory layout suitable for vectorization in a CPU without scatter/gather (which you may want to avoid anyway if seeking ultimate performance).
Dealing with this issues requires a good understanding of these issues, the language and the compiler's modus operandis.
Fundamentally, arrays in any language are trivial when at the microscopic language but choosing the right strategy for the full program can be a challenge in any language.

Third, having spent more time that I'd like trying to hammer into a few scientists that you need to avoid loops and use array operations to get good performance out of MATLAB®, I would say that some scientists' brains are better suited to hand writing loops than array manipulation.

stupid me... forgot the tags

void f(int n, float *a, float *b, float *z)
{
        int i;
        for(i = 0; i &lt n; i++)
                z[i] = a[i]+b[i];
}

I suspect Fortran makes it easier for compiler writers, but for the compiler user the difference is tiny.
Both GCC and ICC can vectorize the following piece of code, by generating code with a run-time check for aliasing and two paths: a vectorized path and a scalar path.

This code is pretty trivial, but I think the method is valid for most(all?) possible uses of Fortran arrays.

In my experience, with a bit of care in code writing (and reading the compiler's vectorization reports), ICC can vectorize pretty complex, but readable, standard and portable, loops.

void f(int n, float *a, float *b, float *z)
{
        int i;
        for(i = 0; i

ATLAS is mostly written in C with a ton of compiler SIMD intrinsics.
It provides a Fortran BLAS and partial LAPACK interface, along with a C BLAS interface.

As you said, YMMV.
From your description, it seems that in your field you spent most of your CPU time performing a relatively small number of large and time consuming operations on matrices. This can be efficiently handled by an interpreted language (Python, MATLAB, etc) with an efficient underlying implementation of matrix operations.
Some of those implementations have a very long history and they're written in Fortran, with C interfaces available (which is how they're built into Python and Matlab).
And there isn't any kind of pressing need to re-write them into C or whatever.

Other areas have different profiles.
Particle physics is completely different. Most of the CPU time is spend a very large number of tiny operations, comparisons and branching.
Such code needs to be written in a compiled language, like Fortran or C/C++.
And the choice nowadays for new code is, by far, C/C++. They even rewrote their main simulation package (GEANT) from Fortran to C++. I think they really felt the need of OOP to handle complex models.

More generally, most _new_ critical loop parts are written in C/C++, albeit with the possible usage of old Fortran libraries in the cases they exist.
And non critical loop parts are often written in Python or etc.

Wrong.
The Linux Bluetooth stack lives outside the kernel. Bluetooth audio devices are not accessible as OSS or ALSA hardware devices.
There is an alsalib plugin that lets alsa applications talk to Bluetooth audio, but it's got a number of limitations.

PulseAudio provides transparent, robust, behavior for both OSS/ALSA hardware devices and Bluetooth devices (as long as network).