There are probably very few people on this globe who at some point in time haven’t heard the term ‘Higgs Boson’ zip past, along with the term ‘God Particle’. As during the 2010s the scientists at CERN were trying to find evidence for the existence of this scalar boson and with it evidence for the existence of the Higgs field that according to the Standard Model gives mass to gauge bosons like photons, this effort got communicated in the international media and elsewhere in a variety of ways.
Along with this media frenzy, the physicist after whom the Higgs boson was named also gained more fame, despite Peter Higgs already having been a well-known presence in the scientific community for decades by that time until his retirement in 1996. With Peter Higgs’ recent death after a brief illness at the age of 94, we are saying farewell to one of the big names in physics. Even if not a household name like Einstein and Stephen Hawking, the photogenic hunt for the Higgs boson ended up highlighting a story that began in the 1960s with a series of papers.
Windows 95 was an amazing operating system that would forever transform the world of home computing, setting the standard for user interaction on a desktop and quite possibly was the OS which had the longest queue of people lining up on launch day to snag a boxed copy. This raises the question of why we still don’t write software for this amazing OS, because ignoring the minor quibbles of ‘security patches’ and ‘modern hardware compatibility’, it’s still has pretty much the same Win32 API as supported in Windows 11, plus it doesn’t even spy on you, or show you ads. This line of reasoning led [MattKC] recently to look at easy ways to port modern applications to Windows 95.
In the video, the available options are ticked off, starting with straight Win32 API. Of course, nobody writes for the Win32 API for fun or to improve their mental well-being, and frameworks like WxWidgets and QuteQt have dropped support for Windows 9x and generally anything pre-Win2k for years now. The easiest option therefore might be Microsoft’s .NET framework, which in its (still supported) 2.0 iteration actually supports Windows 98 SE, or basically within spitting distance of running it on the original Win95.
The central selling point of qubit-based quantum processors is that they can supposedly solve certain types of tasks much faster than a classical computer. This comes however with the major complication of quantum computing being ‘noisy’, i.e. affected by outside influences. That this shouldn’t be a hindrance was the point of an article published last year by IBM researchers where they demonstrated a speed-up of a Trotterized time evolution of a 2D transverse-field Ising model on an IBM Eagle 127-qubit quantum processor, even with the error rate of today’s noisy quantum processors. Now, however, [Joseph Tindall] and colleagues have demonstrated with a recently published paper in Physics that they can beat the IBM quantum processor with a classical processor.
In the IBM paper by [Yougseok Kim] and colleagues as published in Nature, the essential take is that despite fault-tolerance heuristics being required with noisy quantum computers, this does not mean that there are no applications for such flawed quantum systems in computing, especially when scaling and speeding up quantum processors. In this particular experiment it concerns an Ising model, a statistical mechanical model, which has many applications in physics, neuroscience, etc., based around phase transitions.
Unlike the simulation running on the IBM system, the classical simulation only has to run once to get accurate results, which along with other optimizations still gives classical systems the lead. Until we develop quantum processors with built-in error-tolerance, of course.
Using technologies like electron microscopy (EM) it is possible to capture molecular mechanisms in great detail, but not when these mechanisms are currently moving. The field of cryomicroscopy circumvents this limitation by freezing said mechanism in place using cryogenic fluids. Although initially X-ray crystallography was commonly used, the much more versatile EM is now the standard approach in the form of cryo-EM, with recent advances giving us unprecedented looks at the mechanisms that quite literally make our bodies move.
Myosin-5 working stroke and walking on F-actin. (Credit: Klebl et al., 2024)
The past years has seen many refinements in cryo-EM, with previously quite manual approaches shifting to microfluidics to increase the time resolution at which a molecular process could be frozen, enabling researchers to for example see the myosin motor proteins go through their motions one step at a time. Research articles on this were published previously, such as by [Ahmet Mentes] and colleagues in 2018 on myosin force sensing to adjust to dynamic loads. More recently, [David P. Klebl] and colleagues published a research article this year on the myosin-5 powerstroke through ATP hydrolysis, using a modified (slower) version of myosin-5. Even so, the freezing has to be done with millisecond accuracy to capture the myosin in the act of priming (pre-powerstroke).
The most amazing thing about cryo-EM is that it allows us to examine processes that used to be the subject of theory and speculation as we had no means to observe the motion and components involved directly. The more we can increase the time resolution on cryo-EM, the more details we can glimpse, whether it’s the functioning of myosins in muscle tissue or inside cells, the folding of proteins, or determining the proteins involved in a range of diseases, such as the role of TDP-43 in amytrophic lateral sclerosis (ALS) in a 2021 study by [Diana Arseni] and colleagues.
As our methods of freezing these biomolecular moments in time improve, so too will our ability to validate theory with observations. Some of these methods combine cryogenic freezing with laser pulses to alternately freeze and resume processes, allowing processes to be recorded in minute detail in sub-millisecond resolution. One big issue that remains yet is that although some of these researchers have even open sourced their cryo-EM methods, commercial vendors have not yet picked up this technology, limiting its reach as researchers have to cobble something together themselves.
Hopefully before long (time-resolved) cryo-EM will be as common as EM is today, to the point where even a hobby laboratory may have one lounging around.
The Bendix Corporation’s Bendix G-15 was introduced in 1956 as an affordable system for industrial and scientific markets. As with any computer system, a range of peripheral devices for input and output were available, which includes an electric typewriter. Produced by IBM, this typewriter was heavily modified by Bendix, with the version that [Usagi Electric] got their mittens on being equipped with a gigantic 28″ platen. With just power applied to the machine it will even still work as a regular electric typewriter, but it can do much more.
The bits that make an IBM electric typewriter into a Bendix G-15 accessory. (Credit: Usagi Electric)
Most typewriters for the G-15 have a much smaller platen, as can be seen in the brochures for the system. The typewriter is connected together with other peripherals like plotters, card punches and tabulators via a coupler which uses a 5-bit interface. For the encoding on this interface no standard encoding is used, but rather 4 bits are used as data followed by 1 bit to indicate a command. In addition a number of other signal lines are used with the Bendix G-15, which allows control over the punch card reader and run status on the computer from the comfort of the typewriter’s desk.
In addition to the added electronics that communicate with the Bendix G-15, there are also solenoids and sensors which interface with the typewriter’s keyboard. This is what allows for command keys on the typewriter to be recorded separately along with the regular number and letter keys, in addition to the Bendix G-15 using the typewriter to automatically type on the paper. After a good cleaning session the typewriter’s basic functionality is restored, with the hope that once the Bendix G-15 over at the Usagi Farm can power up its DC circuit both will happily chat with each other. Color us excited.
Alan Kirby (left) and Mark Kempf with the LANBridge 100, serial number 0001. (Credit: Alan Kirby)
When Ethernet was originally envisioned, it would use a common, shared medium (the ‘Ether’ part), with transmitting and collision resolution handled by the carrier sense multiple access with collision detection (CSMA/CD) method. While effective and cheap, this limited Ethernet to a 1.5 km cable run and 10 Mb/s transfer rate. As [Alan Kirby] worked at Digital Equipment Corp. (DEC) in the 1980s and 1990s, he saw how competing network technologies including Fiber Distributed Data Interface (FDDI) – that DEC also worked on – threatened to extinguish Ethernet despite these alternatives being more expensive. The solution here would be store-and-forward switching, [Alan] figured.
After teaming up with Mark Kempf, both engineers managed to convince DEC management to give them a chance to develop such a switch for Ethernet, which turned into the LANBridge 100. As a so-called ‘learning bridge’, it operated on Layer 2 of the network stack, learning the MAC addresses of the connected systems and forwarding only those packets that were relevant for the other network. This instantly prevented collisions between thus connected networks, allowed for long (fiber) runs between bridges and would be the beginning of the transformation of Ethernet as a shared medium (like WiFi today) into a star topology network, with each connected system getting its very own Ethernet cable to a dedicated switch port.
Do you really need that cloud hosting package? If you’re just running a website — no matter whether large or very large — you probably don’t and should settle for basic hosting. This is the point that [Thomas Millar] argues, taking the reader through an example of a big site like Business Insider, and their realistic bandwidth needs.
From a few stories on Business Insider the HTML itself comes down to about 75 kB compressed, so for their approximately 200 million visitors a month they’d churn through 30 TB of bandwidth for the HTML assuming two articles read per visitor.
This comes down to 11 MB/s of HTML, which can be generated dynamically even with slow interpreted languages, or as [Thomas] says would allow for the world’s websites to be hosted on a system featuring single 192 core AMD Zen 5-based server CPU. So what’s the added value here? The reduction in latency and of course increased redundancy from having the site served from 2-3 locations around the globe. Rather than falling in the trap of ‘edge cloud hosting’ and the latency of inter-datacenter calls, databases should be ideally located on the same physical hardware and synchronized between datacenters.
In this scenario [Thomas] also sees no need for Docker, scaling solutions and virtualization, massively cutting down on costs and complexity. For those among us who run large websites (in the cloud or not), do you agree or disagree with this notion? Feel free to touch off in the comments.
