https://en.wikipedia.org/wiki/Indo-Aryan_migrations

There is an old but still good list of transceivers with this feature here: https://www.servethehome.com/sfp-to-10gbase-t-adapter-module...

I recommend looking for a used laptop with a Core Ultra 7 165U (<$500) or a Core Ultra 7 268V (>$1000). Maybe an HP EliteBook. Either one would be faster than your old i9 and run much cooler.

On Ubuntu, Arch, Mint, etc. there is no such distinction. Everything is made of packages, including the base system. You have packages for the kernel, the init system, logging, networking, firmware, etc. These are all versioned independently and whether or not they are considered "essential" is up to the user to decide.

On BSD, the base system is not composed of packages. It is a separate thing, with the kernel, libc, command line utilities all tightly coupled and versioned together. This allows the components to evolve together, with breaking ABI changes that would not be practical in Linux. This makes BSD better for research, which is why things like IPv6, address space randomization, SSH, jails, capabilities were developed there.

Packages are used for applications and are isolated to /usr/local. Dependency and compatibility problems only exist for packages. The base system is always there, always bootable, and you can count on being able to log in to a command line session and use the standard suite of tools. It is sort of like a Linux rescue image, except you boot off it every time.

https://web.archive.org/web/20190906055006/http://home.pipel...

Today, it seems like a normal solution to the problem to me, and the controversy seems silly. I have much experience with the map function from Javascript. It is too simple to be objectionable.

But in the '90s, I would also have had trouble understanding the transform. Lambdas/closures were unheard of to everyone except Lisp dweebs. Once I figured out what the code was doing, I would be suspicious of its performance and memory consumption. This was 1994! Kilobytes mattered and optimal algorithmic complexity was necessary for anything to be usable. Much safer to use a well understood for loop. I have plenty of experience making those fast, and that's what map() must be doing under the hood anyway.

But I would have been wrong! map() isn't doing anything superfluous and I can't do it faster myself. The memory consumption of the temporary decorated array is worth it to parse the last word N times instead of N log N times. Lisp is certainly a slow language compared to C, but that's not because of its lambdas!

In 2012, Behdad Esfahbod wrote Glyphy, an implementation of SDF that runs on the GPU using OpenGL ES. It has been widely admired for its performance and enabling new capabilities like rapidly transforming text. However it has not been widely used.

Modern operating systems and web browsers do not use either of these techniques, preferring to rely on 1990s-style Truetype rasterization. This is a lightweight and effective approach but it lacks many capabilities. It can't do subpixel alignment or arbitrary subpixel layout, as demonstrated in the article. Zooming carries a heavy performance penalty and more complex transforms like skew, rotation, or 3d transforms can't be done in the text rendering engine. If you must have rotated or transformed text you are stuck resampling bitmaps, which looks terrible as it destroys all the small features that make text legible.

Why the lack of advancement? Maybe it's just too much work and too much risk for too little gain. Can you imagine rewriting a modern web browser engine to use GPU-accelerated text rendering? It would be a daunting task. Rendering glyphs is one thing but how about handling line breaking? Seems like it would require a lot of communication between CPU and GPU, which is slow, and deep integration between the software and the GPU, which is difficult.

I frequently use c (change) on my visual selections, type in new code at the point where it was removed, then use p to paste the old code somewhere else.