A windowless telecommunications hub, 33 Thomas Street in New York City embodies an architecture of surveillance and paranoia. That has made it an ideal set for conspiracy thrillers.

When it was completed in Lower Manhattan in 1974, 33 Thomas Street, formerly known as the AT&T Long Lines Building, was intended as the world’s largest facility for connecting long-distance telephone calls. 1 Standing 532 feet — roughly equivalent to a 45-story building — it’s a mugshot for Brutalism, windowless and nearly featureless. Its only apertures are a series of ventilation hoods meant to hide microwave-satellite arrays, which communicate with ground-based relay stations and satellites in space. One of several long lines buildings designed by John Carl Warnecke for the New York Telephone Company, a subsidiary of AT&T, 33 Thomas Street is perhaps the most visually striking project in the architect’s long and influential career. Embodying postwar American economic and military hegemony, the tower broadcasts inscrutability and imperviousness. It was conceived, according to the architect, to be a “skyscraper inhabited by machines.”

source: HN

We analyzed this scene using Nvidia’s Nsight Graphics and AMD’s Radeon GPU Profiler to get some insight into why Starfield performs the way it does. On the Nvidia side, we covered the last three generations of cards by testing the RTX 4090, RTX 3090, and Titan RTX. On AMD, we tested the RX 7900 XTX. The i9-13900K was used to collect data for all of these GPUs.

source: HN

The Book8088 is trying hard to basically be compatible with the original IBM PC, containing some of the same or equivalent chips. It’s natural to want to put it through its paces, and one of the best tests for IBM PC compatibility has to be the 8088MPH demo. If 8088MPH will run we must be operating pretty darn close to the original.

Now, as it turns out, most of the demo does run, albeit in RGBI mode which loses out on all the cool composite artifact color effects. But most notably the famous Kefrens Bars effect does not display - the screen just goes blank. What’s going wrong on the Book8088 vs a real IBM PC 5150?

source: HN

A notoriously fickle vegetable to harvest, Yorkshire forced rhubarb is anything but easy to grow. It thrives in the county’s cold winters, but if the soil is too wet, it can’t be planted. If the temperature is too hot, it won’t grow; and 10 or more frosts are needed before a farmer can even think about forcing it. Only then can horticulturalists remove the heavy roots from the field, then clean and replant them inside the forcing sheds where photosynthesis is limited, encouraging glucose stored in the roots to stimulate growth. It demands patience, expertise and good fortune, and, ultimately, it is engineered for maximum taste: once deprived of light, the vegetable is forced to use the energy stored in its roots, making it far sweeter than the normal variety.

source: HN

Choosing to use a block range index (BRIN) to query a field with high correlation is a no-brainer for the optimizer. The small size of the index and the field’s correlation makes BRIN an ideal choice. However, a recent event taught us that correlation can be misleading. Under some easily reproducible circumstances, a BRIN index can result in significantly slower execution even when the indexed field has very high correlation.

source: HN

I have been reading Doom Guy by John Romero. It is an excellent book which I highly recommend. In the ninth chapter, John describes being hit by lightning upon seeing Adaptive Tile Refresh (ATS). That made me realize I never took the time to understand how this crucial piece of tech powers the Commander Keen (CK) series.

At its heart the problem ATS solves is bandwidth. Writing 320x200 nibbles (32 KiB) per frame is too much for the ISA bus. There is no way to maintain a 60Hz framerate while refreshing the whole screen. If we were to run the following code, which simply fills all banks, it would run at 5 frames per seconds.

source: HN

In 1969, Harry amazed everybody with a little electronic gadget he’d built which, using the primitive digital integrated circuits of the time, generated random music, played it through a speaker, and flashed lights on its front panel. It was precisely what people expected computers to do, based upon portrayals in the movies and on television, and yet it could be held in your hand and was, internally, very simple. He explained how it worked, and I immediately knew I had to have one. Digital electronics was in a great state of flux at the time, with each manufacturer launching their own line of integrated circuits, most incompatible with one another, so there was no point in slavishly reproducing Harry’s design. Starting from the concept, I designed my own gadget from scratch, using Signetics Utilogic diode-transistor small scale integration integrated circuits which were popular at the time but shortly thereafter made obsolete by 7400 series transistor-transistor logic (TTL). The architecture was identical to Harry’s device, but I opted for more with-it and less power-hungry light-emitting diodes (LEDs) for the display instead of the incandescent bulbs he used. I built the electronics assembly on a sheet of perforated board using wire-wrap fabrication (some people look down their noses at wire-wrap today, but it was good enough for the Apollo Guidance Computer and almost every mainframe backplane of the 1960s, and my wire-wrapped electronics works perfectly fifty years later.)

Little did I imagine, when designing and building the Mind Grenade hardware in 1969, that fifty years later I’d be emulating it on a computer which ran more than a thousand times faster than the one I used in my day job at the time and, furthermore, was sitting on my own desk. But here we are. Thanks to HTML5 and JavaScript, it is now possible to emulate the hardware Mind Grenade entirely in software that runs within any modern Web browser. Below is an abstracted version of the Mind Grenade front panel. Press the power button at the bottom to get things going. The slider at the left controls the pitch and the slider at the right sets the rate at which the notes play. The check boxes below the lights select any of the 16 possible tunes that can be played.

source: HN

While browsing through ssh-agent’s source code, we noticed that a remote attacker, who has access to the remote server where Alice’s ssh-agent is forwarded to, can load (dlopen()) and immediately unload (dlclose()) any shared library in /usr/lib on Alice’s workstation (via her forwarded ssh-agent, if it is compiled with ENABLE_PKCS11, which is the default).

Surprisingly, by chaining four common side effects of shared libraries from official distribution packages, we were able to transform this very limited primitive (the dlopen() and dlclose() of shared libraries from /usr/lib) into a reliable, one-shot remote code execution in ssh-agent (despite ASLR, PIE, and NX). Our best proofs of concept so far exploit default installations of Ubuntu Desktop plus three extra packages from Ubuntu’s “universe” repository. We believe that even better results can be achieved (i.e., some operating systems might be exploitable in their default installation):

source: HN

Let’s abuse a bug in java.lang.String to make some weird Strings. We’ll make “hello world” not start with “hello”, and show that not all empty Strings are equal to each other.

source: HN

The Intel i960 was a remarkable 32-bit processor of the 1990s with a confusing set of versions. Although it is now mostly forgotten (outside the many people who used it as an embedded processor), it has a complex history. It had a shot at being Intel’s flagship processor until x86 overshadowed it. Later, it was the world’s best-selling RISC processor. One variant was a 33-bit processor with a decidedly non-RISC object-oriented instruction set; it became a military standard and was used in the F-22 fighter plane. Another version powered Intel’s short-lived Unix servers. In this blog post, I’ll take a look at the history of the i960, explain its different variants, and examine silicon dies. This chip has a lot of mythology and confusion (especially on Wikipedia), so I’ll try to clear things up.

source: HN

FSR 2, or FidelityFX Super Resolution 2, is a temporal upscaling (TAAU) algorithm developed by AMD. It is comparable to Nvidia’s DLSS, except it is completely open-source and doesn’t require vendor-specific GPU features (tensor cores) to run.

I’ve been floating the idea of making an OpenGL backend for FSR 2 for a while now. However, only recently have I acquired the motivation to actually do it. I knew that writing a bespoke TAA(U) implementation, let alone a good one, was a task worthy of the gods, so I wanted to defer it to them.

source: HN

A few days ago, DeepMind published a blog post talking about a paper they wrote, where they discovered tinier kernels for sorting algorithms. They did this by taking their deep learning wisdom, which they gained by building AlphaGo, and applying it to the discipline of of superoptimization. That piqued my interest, since as a C library author, I’m always looking for opportunities to curate the best stuff. In some ways that’s really the whole purpose of the C library. There are so many functions that we as programmers take for granted, which are the finished product of decades of research, distilled into plain and portable code.

DeepMind earned a fair amount of well-deserved attention for this discovery, but unfortunately they could have done a much better job explaining it.

https://www.deepmind.com/blog/alphadev-discovers-faster-sorting-algorithms

source: HN

Now it became immediately obvious to my why HiCA only supports acme.sh. They are not conforming to ACME at all! (Bugs the heck outa me that they’re using the official ACME logo on their site even though they don’t implement the ACME standard.)

Instead, HiCA is stealthily crafting curl commands and piping the output to bash. acme.sh is (being tricked into?) running arbitrary code from a remote server.

source: HN

Note that your server will almost definitely hang, requiring a physical (or IPMI) reboot, because no interrupts, including NMIs, can be delivered to the zombie cores: this means no scheduler, no IPIs, nothing will work.

source: HN

So then bytes 3 and 4 should be that 16-bit payload length — and this is where things fall apart. The ws message says we have 126 bytes (00000000 01111110) of payload. That sounds plausible. The undici message says we have 25,888 bytes (01100101 00100000) of payload … in a 222 byte packet? Yeah: this one is fishy.

source: HN

The bottom line is, as we’ll demonstrate in the next few screenshots, this laptop isn’t just a MIPS laptop: it’s three apparently completely independent RISC systems with their own memory, flash and operating system on an internal Ethernet network. All those NIC and switch chips are the internal communication interfaces from the Au1550 to the IXP425 and the AR2316A, but using the IDE bus lines instead of actual twisted pair. That’s not what I was expecting to find in a Sun Ray!

source: HN

I inspected Heroku’s logs again and saw that it wasn’t just this specific task that was being dispatched twice, all of them were:

See, at this point the celerybeat dyno shouldn’t even exist. It was nowhere to be found on my list of dynos. But here it is, alive, well, and scheduling tasks.

source: HN

ROP methods have become increasingly sophisticated
But we can identify system behaviours which only ROP code requires
We can contrast this to what Regular Control Flow code needs
And then, find behaviours to block

source: HN

As it turns out, there is a reason that there is no good Scheme implementation on WebAssembly: the initial version of WebAssembly is a terrible target if your language relies on the presence of a garbage collector. There have been some advances but this observation still applies to the current standardized and deployed versions of WebAssembly. To better understand this issue, let’s dig into the guts of the system to see what the limitations are.

source: HN

In every modern OS, GPU drivers are split into two parts: a userspace part, and a kernel part. The kernel part is in charge of managing GPU resources and how they are shared between apps, and the userspace part is in charge of converting commands from a graphics API (such as OpenGL or Vulkan) into the hardware commands that the GPU needs to execute.

Between those two parts, there is something called the Userspace API or “UAPI”. This is the interface that they use to communicate between them, and it is specific to each class of GPUs! Since the exact split between userspace and the kernel can vary depending on how each GPU is designed, and since different GPU designs require different bits of data and parameters to be passed between userspace and the kernel, each new GPU driver requires its own UAPI to go along with it.

source: HN