holowoodman

But the potential of easy optimization does not mean that they will be optimized. Compilers for higher-level languages are full of broken promises around their potential. "Faster than C because we can optimize" is never really realized, except in maybe one benchmark that only works in that one exact scenario and nowhere in my code...

> So then why bother with cities at all? High rises are just a different constant factor relative to 40 acre farms after all.

Because of the logarithmic scaling of infrastructure (like supermarkets, doctors, hospitals), and because of the square root scaling of people-density per area vs. total travel distance to said infrastructure.

>> moving goods instead of people scales logarithmically > This is obviously false. There's some average parcel size, and an associated maximum capacity for a delivery van.

You do move bananas by ship from continent to continent. Then you split it up, move it by smaller ships up-river. Then you split it up, move it by truck to each cities distribution center. Then you split it up, move it by smaller truck to each store. Then people buy it.

Obviously logarithmic and the whole reason for ships and freight trains to exist, otherwise we would all get our tropical fruit in person by airplane.

And since we are on a CS-heavy site, talking about scalability, constant factors are irrelevant. That is what scalability means. It is the extrapolation to big numbers, where those constants no longer matter anymore. Of course there might be a local equilibrium for sufficiently small numbers. But that is always temporary as humanity keeps growing.

Yes. But if you look at the electricity system map, you'll see that those are mostly north-south connections through easy transitions. They skip the south of France, east of Poland. Some of those routes use different locomotives than all the others. And the number of border crossings is limited for that reason.

No. Less brittle than normal glass, but not as good as certain ceramics.

But as soon as that happens, other gemstones will come in cheaper artificial varieties as well.

Public transit also doesn't scale. Germany, during the Covid years, introduced a cheap country-wide flat fee ticket (~50 bucks per month, all you can ride) for public transit. Which lead to road traffic going down measurably. Which lead to trains and busses being packed, people traveling more and farther on those. Leading to higher cost, degraded service and packed bus stations and rail lines. Building more of those isn't possible geometrically as well, cities are already packed. We are currently, at tremendous cost and effort, moving railway lines and stations underground, like Stuttgart 21, for that reason.

The point is, moving people inherently is bad. Shifting from cars to public transit reduces the badness a little, but you still need infrastructure that scales O(p * s * f), where p is the number of people, s is the average distance travelled per journey, and f is the frequency of journeys. Scaling doesn't change the slightest bit with public transit, you just have a different constant factor which is irrelevant for scalability.

So the solution isn't public transit. It is the avoidance of any unnecessary travel, meaning that we actually need something like a tax on non-home-office jobs and stores that you personally have to visit (as opposed to shopping online). We need better delivery infrastructure so people don't need to travel. We need close-to-home shopping options. Because actually moving goods instead of people scales logarithmically, the network of countrywide, regional, local distribution centers, bigger shops, smaller shops behaves like a tree.

The European network is far more fragmented than it seems. There are differences in power supply, track width, station and tunnel width and signalling such that you cannot easily cross borders in a train. There are lots of trains that are equipped for multiple signalling standards and have variable axles. But in general, you can only go to the immediate neigbouring countries, as soon as you cross another border you have to change trains. In some countries, like France, you even have concurring standards within the same network. A hypothetical Lisbon-Moscow connection would need to change trains at least 2, maybe 3 times.

I don't think, therefore, that "total track length" has any useful meaning in Europe.

Here is some maps to illustrate my point:

https://commons.wikimedia.org/wiki/File:Europe_rail_electrif...

https://en.wikipedia.org/wiki/Track_gauge_in_Europe#/media/F...

I'm saying that just compiling a kernel with stuff not compiled in is misuse-proof. That way you can disable io_uring entirely (but not accept()).

Which would be prone to misconfiguration, accidents and exploits. Better to not include it at all.

seccomp BPF, eBPF, in a way SELinux/AppArmor/Tomoyo/..., maybe you can even call namespaces some kind of syscall filter. And then there is the auditing framework, where you can at least record which critical syscalls were performed.

Nowadays its mostly a combination of eBPF, SELinux and auditd plus namespaces in case of containers. Usually in the combination that some distro ships, so nothing really fancy.

This just reinforces the (maybe unfounded) impression that security is a secondary consideration, and performance is primary.

I'd use io_uring in a heartbeat on a dedicated system where the job is only I/O and security isolation isn't a concern. But multiuser/multiapplication/networked? Not a chance.

It wasn't locked in, but the general trend even back then was towards RISC, or at least CISC plus superscalar execution (meaning the processor translates to RISC internally). All the more complex instruction sets were a failure for a reason. Performance was just not there, and bytecode interpretation in software is more flexible.

Problem is, unsafe rust is as crappy as C/C++ safety-wise, just with worse tooling. And lots of things that C/C++ does can't be done without unsafe rust.

Rust will never take over and something like C/C++ will always be with us.

Everyone with lower-level systems programming or hardware experience did know after taking a look that Java bytecode was unfit for direct execution by a CPU. All the bits that you need to make decoding and execution fast in hardware were just missing. And the instruction set is complex in a way that makes the most complex CISC instructions look almost like RISC. You basically would have to put another decoder stage into processors, to make java bytecode into CISC and that into RISC.

Only applications and web people did believe that particular part of the hype, because they didn't know what it took. And IBM consultants believed it because IBM always managed to sell some weird CPU extension for big dollars that did weird stuff, like their "decode XML extension".

Java might be memory-safe. But it is "performance-unsafe".

The original article is about AI. Then about machine learning. Then about AI...

The author doesn't seem to make up his mind about it. Or the article is AI-generated slop maybe.

Yes, so much this. It used to be that important logs (filtered by severity and keywords) were even continuously live-printed by a line printer, so that there was always a current paper copy of the really important stuff for forensics.

See e.g. https://www.youtube.com/watch?v=FiEGoVzmyvs but dot-matrix was also used and at least a little less noisy.

One thing is that context switches have become less of a problem with the advent of multicore systems. But we are not at a place where you can have your dedicated filesystem core for each filesystem, so they are still relevant.

And yes, CPUs are generally optimized not for context switches, but for numerics and certain single-application benchmarks. So computations without any context switches are very fast. Application to Kernel switches are somewhat fast as well. But application-to-application or even worse application-kernel-privilegedFSprocess-kernel-application will be slow as hell, because those numbers never make it to the TOP500 or benchmark sites.

Context switches also have already been optimized too much, Spectre and Meltdown in all their variants are a certain kind of botched context switch. That means that certain optimizations are now out of the question, context switches will be optimized more carefully (if at all) in the future. So there isn't too much hope for a faster but still secure context switch.

I think the actual future in a decade or so will rather have more cores, less context switches and a more computer-network-like CPU. You will have your filesystem server process on the filesystem/disk-IO core and you will speak some filesystem protocol via shared memory over a on-CPU network.

FUSE is what a microkernel filesystem would look like. There are some optimisations that FUSE doesn't do, that microkernels usually have. In the most extreme form, L4 trims down communication primitives to the most efficient platform-specific ways of exchanging memory buffers. In all cases, microkernels and FUSE still need context switches for everything, and those are expensive. If you leave out the context switches, you don't have a microkernel anymore. This is what Windows did by pulling graphics drivers into the kernel, because context switches are slow.

So no. Microkernels have been tried. Microkernel-workalike filesystems are here with FUSE. They suck because microkernels suck when you need performance. Research has gone into different directions, like microkernels as hypervisors and for security, because it has become clear that the performance problems if microkernels are inherent and unfixable.

Not so sure that EU bureaucrats will understand and fix that problem. With NIS2, they let the IT-security-crapware lobby dictate draconian and mostly stupid security laws. Could be that the security-paranoid part of the bureaucracy overrides the consumer protection part in that case.

> In which applications do people use both logarithms and base 10 as the default?

Engineering. For example dB is defined in base 10.

No. Usually log without further specification is base10.

Except in mathematics and physics, where it usually is base e.

Except sometimes in computer science, where it can be base 2.

But there are more of those weirdnesses: "ld" can be "log decimal", so base 10; or "logarithmus dualis", so base 2. Base 2 is also sometimes written as "lb" (log binary). You really need to know the conventions of the field/subfield to know which is which.

Which leads to the common trick: If a train is delayed, it will often skip the last stop and turn at a station before the last. So the train was cancelled and not late at the final destination, therefore doesn't affect the punctuality statistics.

And yes, in Germany this happens and is reflected in rising "cancelled train" statistics. KPIs for Deutsche Bahn managers haven't caught up yet ;)

It's just a difference in aims and circumstances. Japan has multiple train companies operating different networks, so a separate network was the only thing they could build. France accepted the compromise that high-speed TGV stations are far outside of the city areas, like airports, which makes nominal travel times fast, but the first and last miles will always be slow local trains to the city centre. Germany wanted ICE passengers to arrive at the central train station of a city, so using the existing train network at least partially is the only possibility. China has larger distances and no preexisting dense network, so building separate and dedicated is easier. Also, they maybe don't fuss about tearing down a few buildings and disowning a few home-owners who are in the way of their new dedicated high-speed route and station.

With VAG, at least everyone knows the deal.

E.g. Mercedes uses Renault engines in the less-fancy models, but most customers are kept in the dark about that.

Yes, you can buy a Dacia for below 20kEur, but even those have gotten far more expensive lately. It used to be that around 10 years ago, a Dacia Logan (typical station wagon family car) could be had for 11kEur. Nowadays the comparable Dacia Duster (SUV instead of station wagon, but somewhat similar slightly smaller internal space) will set you back 18kEur. Most of this price hike is claimed to come from mandatory electronics like eCall, collision avoidance, fatigue sensors, more complex bodywork due to crash requirements, as well as more complex engines due to emission controls.

With your quoted Renault EV models, you really have to be careful, often they don't give the full price but just the price without battery. The battery has to be bought or rented separately.

France has a separate high-speed train network, so speed differences between high-speed (TGV) and low-speed (freight, low class passenger) trains don't cause inefficiencies.

Switzerland doesn't have high-speed trains, only low-speed ones. And all timetables are carefully tuned to half- or full-hour station distance intervals that all trains on a track take at the same speed ("Taktfahrplan").

Germany has the worst of all those worlds: No Taktfahrplan (because it probably would be impossible due to the larger and far more complex network), high- and low-speed trains on the same tracks, and only some sections of dedicated high-speed rail that drive up the cost but still have shared stations and sections with low-speed rail so that punctuality goes down when the tiniest thing goes wrong.

Higher speeds reduce efficiency.

The most efficient use of the tracks would be to limit all trains to the speed of the slowest train that travels a route. Then you can have minimal distances between trains.

Also, faster trains are less fuel-efficient, quadratically with speed. So a slowdown would help the environment and the throughput. The only thing it wouldn't improve is passenger happiness ;)

Yes, but that would be another set of libraries and another recompilation. Sticking with 32bit code is mostly to avoid that.

Obviously that incentive difference doesn't work. Otherwise Apple would be happy with being paid, while not making users the product. Cable TV is another example of this non-working incentive difference. It just takes longer, because the paying users need to be slowly dragged along into advertisement hell.