An efficient circulatory system and myelinated nerves.

At small sizes, the circulatory and respiratory systems of insects work better (less friction for blood in the absence of capillaries and less friction for the air that circulates as a gas through the body), but at big sizes those of vertebrates work better, due to efficient pumping.

The myelinated nerves have the same speed for propagating nervous signals as non-myelinated nerves that are much thicker, so thick that an insect could not have many such nerves. At small sizes this does not matter, but at big sizes if the nerves are not fast enough the reaction times of an animal can become too slow, e.g. the head might need a big fraction of a second until noticing that something bites the tail.

The combined results are that an insect as big as a typical vertebrate would react mostly sluggishly and it would be able of only very short bursts of intense activity, before becoming tired. This would put it at a serious disadvantage.

Nonetheless, the biggest dinosaurs were several times heavier than the heaviest terrestrial mammals that have ever lived, which in turn were several times heavier than the biggest elephants of today.

So probably dinosaurs were close to the size limit that is imposed by the mechanical properties of vertebrate tissues like bones, tendons and muscles, while in the present terrestrial mammals the size is limited by the availability of food and by the humans who have always hunted preferentially the biggest animals they encountered, and not by the strength of their bones.

So I believe that if for you the "interactivity" does not seem better, that is more likely to be caused by being much more familiar about how cubic Beziers behave, from past experience, than because these hyperbezier curves were really less suited for interactivity. Also, the current implementation in JavaScript seems buggy.

For me, the poor approximation by cubic Beziers of some important curves, like conics and the Euler spiral, is an extremely serious defect, so I like these hyperbezier curves much more and I intend to investigate how efficient can they be, from a computational viewpoint.

If this will continue for too long, other countries may decide that they want to pass through the strait no matter what USA says. Then what will USA do, declare war on everybody? Threaten to use nuclear weapons against those who want to use the strait?

For decades, USA has used various blackmailing methods to force other countries to follow its policies, but nowadays most countries seek methods to free themselves from these constraints, so it is unclear if USA will be again successful in the future with such tactics.

In terrestrial environments, the average color is typically not much different from the true color of the Sun. The white light of the Sun is split by the atmosphere into the bluish light of the sky and the yellowish direct light, then those are reflected and diffused by various bodies until being collected by an eye or a photographic camera.

If the bodies in the environment are random enough, i.e. there are similar amounts of those which absorb or diffuse different parts of the spectrum (e.g. the environment includes brown earth, green plants, blue sky, variously colored flowers and fruits, etc.), then the average color of the light that reaches the photoreceptors will not differ much from the color of the original source of light, i.e. the Sun as seen from outside the atmosphere.

If the sky is covered with clouds, then the light is white, because the blue sky light is mixed again with the direct Sun light.

If the sky is clear and there is an unobstructed view of it, the light reflected by a white object will be the sum of the light coming from the sky to the object and directly from the Sun to the object, so it will be white. For example this is true for white clouds and white snow.

This, i.e. that the Sun outside the atmosphere is perfectly white, has been understood for a long time, since the 19th century.

I always connect back home when I am away and I want access to a beefier computer. On the home server, "Wake on LAN" is enabled, so I can power it on and off from my home router.

Like for any other packets, you can choose to log such failures, or not. In the parent article the logs are simplified not by the decision of using special authentication packets for opening the SSH port, but by the decision to not log these packets, which is a completely independent decision.

What a remote system could try to determine is not whether IPsec is open, but whether it is possible to initiate a key exchange for IPsec keys. You can easily run IPsec without using a key exchange protocol, by using pre-shared keys. I am not sure whether the last official version of IKE (Internet Key Exchange protocol) provides any reply packet to an initial connection packet that was not authenticated, but in any case it would be easy to customize the key exchange protocol, to not provide any reply.

While TLS is the necessary solution for the communication between computers that have different owners, for the communication between computers that are owned by the same entity IPsec would have been the correct solution (e.g. for connecting your laptop with your home server when you are away), except that the original variant of IPsec had too many completely unnecessary complications, which deterred potential users. Later it was simplified, but it had already acquired a bad reputation of being too difficult to use.

Today the main problem with IPsec remains that there are many stupid firewalls that block without good reasons most protocols and ports. So one may have to run IPsec over some UDP port, instead of running it as an alternative protocol. If even UDP is blocked, one may have to run IPsec over some TCP port, or just over the http or https port (just masquerading it as TCP, not actually running it over TCP, which would mess with flow control).

Moreover, interpreters that offered a complete interactive environment for editing, running and debugging programs, had existed for decades for languages like APL and LISP.

Nonetheless, the availability of Turbo Pascal on cheap computers has probably introduced much more people to such a programming environment than the older alternatives, which were available only on big and expensive computers, so at most they were accessible through time-sharing services in big companies or in universities.

I have used Turbo Pascal on 8080- and Z80-based computers running the CP/M operating system, before becoming able to use IBM PC compatibles, where the Microsoft and Borland C and C++ compilers were a better alternative, and it was a good progress over what I had used previously, but before that, in the university I had used a "Remote Job Entry" system which accessed by time-sharing a computer mainframe from a serial video terminal, and you could do with it everything that you could do with Turbo Pascal (for programs written in Fortran), except that its source code editor was far more awkward (it was a line-oriented text editor, where you could see the source code, but to edit a line it was extracted into a buffer at the bottom of the screen and merged back into the source code when editing it was complete).

On CP/M, Turbo Pascal was the most convenient programming environment, but for serious work, where run-time performance mattered, I was using the Microsoft Fortran compiler for CP/M, enhanced by replacing a few of the subroutines from its run-time library with optimized variants. Pascal is really much too weak for number-crunching problems, even if it may be acceptable for non-numeric problems that are not too complex (the original Pascal does not support multi-file programs, Turbo Pascal was extended in a non-standard way to support this).

This optimally solves the problem of the space taken by logs on disk.

The only possible disadvantage is that any application that is used to scan the logs must decompress them, but in practice I have never seen any case when this caused any nuisance, even when using such a primitive solution like "zcat|grep", instead of a full-featured application.

> But the fundamental conclusion is: the design was wrong. It should not have used mmapped writes. pwrite would have been far better.

It really does not make any sense to use memory-mapped files when writing logs.

Not even pwrite makes sense, because logs should normally be written by opening and using the log files as append-only sequential files.

Only when reading logs, to search for problems, accessing them as read-only memory-mapped files is OK.

Actually not only for logs, but almost always, read-write memory-mapped files are either inefficient or too complex to use (i.e. to avoid problems you must carefully use msync and/or madvise, which eliminates the simplicity that makes memory-mapped files preferable to using pread/pwrite). It is better to use memory-mapped files only for read-only accesses, using the appropriate option flags in open and mmap.

It is just a dedicated computer system, which should be managed by its owner, like any other on-prem servers.

I doubt that it has a good price/performance ratio, but it is a solution for those who feel that they do not want to search, buy, assemble, install and configure every HW/SW component.

It is said that it comes with all hardware and software required to run inference or training with an open weights LLM.

The existence of this product, which competes with cloud-based offerings like those of OpenAI and Anthropic, is presumably the reason why the Palantir CEO criticized very harshly some time ago the business model of OpenAI/Anthropic.

While I doubt that the ethics of Palantir is any better than of OpenAI/Anthropic, in this particular case I have to agree with Alex Karp about "Sovereign AI", i.e. that only losers will make their business completely dependent on an external entity like OpenAI or Anthropic, who are certainly not trustworthy.

I wish this had remained true for its descendants.

The question about LLMs is never whether they can be run, because that has a trivial answer, they can always be run. The right question is what speeds are achievable for representative hardware configurations.

At launch, it is difficult to estimate the speed. That should be known after someone reports experimental results. Moreover, for many LLMs the speed improved sometimes later after their release, after tweaks in inference backends, like llama.cpp or vLLM.

https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-...

to be used for further training/fine-tuning.

https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-...

main model.

https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-...

quantized version of the previous.

https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-...

this "DFlash" model should be used together with one of the previous two "for lower-latency speculative decoding deployments tuned for low-concurrency data center and workstation workflows".

https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-...

like DFlash, the previous model above, but optimized for DGX Spark.