Your new project really could use a block device for Linux. File systems are easy to do with FUSE, but that’s sometimes too high-level. But a block driver can be tough to write and debug, especially since bugs in the kernel’s space can be catastrophic. [Jiri Pospisil] suggestsUblk, a framework for writing block devices in user space. This works using the io_uring facility in recent kernels.
This opens the block device field up. You can use any language you want (we’ve seen FUSE used with some very strange languages). You can use libraries that would not work in the kernel. Debugging is simple, and crashing is a minor inconvenience.
Another advantage? Your driver won’t depend on the kernel code. There is a kernel driver, of course, named ublk_drv, but that’s not your code. That’s what your code talks to.
Space telescopes are all the rage, and rightfully so. The images they take are spectacular, and they’ve greatly increased what we know about the universe. Surely, any picture taken of, say, the Andromeda galaxy before space telescopes would be little more than a smudge compared to modern photos, right? Maybe not.
One of the most famous pictures of our galactic neighbor was taken in — no kidding — 1888. The astronomer/photographer was Isaac Roberts, a Welsh engineer with a keen interest in astrophotography. Around 1878, he began using a 180 mm refracting telescope for observations, and in 1883, he began taking photographs.
He was so pleased with the results that he ordered a reflecting telescope with a 510 mm first-surface mirror and built an observatory around it in 1885. Photography and optics back then weren’t what they are now, so adding more mirrors to the setup made it more challenging to take pictures. Roberts instead mounted the photographic plates directly at the prime focus of the mirror.
Andromeda
This image, captured with the NASA/ESA Hubble Space Telescope, is the largest and sharpest image ever taken of the Andromeda galaxy — otherwise known as M31. This is a cropped version of the full image and has 1.5 billion pixels. You would need more than 600 HD television screens to display the whole image. It is the biggest Hubble image ever released and shows over 100 million stars and thousands of star clusters embedded in a section of the galaxy’s pancake-shaped disc stretching across over 40 000 light-years. This image is too large to be easily displayed at full resolution.
Because it took hours to capture good images, he developed techniques to keep the camera moving in sync with the telescope to track objects in the night sky. On December 29th, 1888 he used his 510 mm scope to take a long exposure of Andromeda (or M31, if you prefer). His photos showed the galaxy had a spiral structure, which was news in 1888.
Of course, it’s not as good as the Hubble’s shots. In all fairness, though, the Hubble’s is hard to appreciate without the interactive zoom tool. And 100 years of technological progress separate the two.
Roberts also invented a machine that could engrave stellar positions on copper plates. The Science Museum in London has the telescope in its collection.
Your Turn
Roberts did a great job with very modest equipment. These days, at least half of astrophotography is in post-processing, which you can learn. Want time on a big telescope? Consider taking an online class. You might not match the James Webb or the Hubble, but neither did Roberts, yet we still look at his plates with admiration.
It is a movie staple to see an overworked air traffic controller sweating over a radar display. Depending on the movie, they might realize they’ve picked the wrong week to stop some bad habit. But how does the system really work? [J. B. Crawford] has a meticulously detailed post about the origins of the computerized air traffic control system (building on an earlier post which is also interesting).
Like many early computer systems, the FAA started out with the Air Force SAGE defense system. It makes sense. SAGE had to identify and track radar targets. The 1959 SATIN (SAGE Air Traffic Integration) program was the result. Meanwhile, different parts of the air traffic system were installing computers piecemeal.
SAGE and its successors had many parents: MIT, MITRE, RAND, and IBM. When it was time to put together a single national air traffic system the FAA went straight to IBM, who glued together a handful of System 360 computers to form the IBM 9020. The computers had a common memory bus and formed redundant sets of computer elements to process the tremendous amount of data fed to the system. The shared memory devices were practically computers in their own right. Each main computing element had a private area of memory but could also allocate in the large shared pool.
The 9200 ran the skies for quite a while until IBM replaced it with the IBM 3083. The software was mostly the same, as were the display units. But the computer hardware, unsurprisingly, received many updates.
If you’re thinking that there’s no need to read the original post now that you’ve got the highlights from us, we’d urge you to click the link anyway. The post has a tremendous amount of detail and research. We’ve only scratched the surface.
We are always amused that we can run emulations or virtual copies of yesterday’s computers on our modern computers. In fact, there is so much power at your command now that you can run, say, a DOS emulator on a Windows virtual machine under Linux, even though the resulting DOS prompt would probably still perform better than an old 4.77 MHz PC. Remember when you could get calculators that ran BASIC? Well, [Calculator Clique] shows off BASIC running on a decidedly modern HP Prime calculator. The trick? It’s running under Python. Check it out in the video below.
Think about it. The HP Prime has an ARM processor inside. In addition to its normal programming system, it has Micropython as an option. So that’s one interpreter. Then PyBasic has a nice classic Basic interpreter that runs on Python. We’ve even ported it to one or two of the Hackaday Superconference badges.
If you ever built a line following robot, you’ll be nostalgic about [Jeremy’s] light-seeking robot. It is a very simple build since there is no CPU and, therefore, also no software.
The trick, of course, is a pair of photo-sensitive resistors. A pair of motors turns the robot until one of the sensors detects light, then moves it forward.
The Internet has spoiled us. You assume network packets either show up pretty quickly or they are never going to show up. Even if you are using WiFi in a crowded sports stadium or LTE on the side of a deserted highway, you probably either have no connection or a fairly robust, although perhaps intermittent, network. But it hasn’t always been that way. Radio networks, especially, used to be very hit or miss and, in some cases, still are.
Perhaps the least reliable network today is one connecting things in deep space. That’s why NASA has a keen interest in Delay Tolerant Networking (DTN). Note that this is the name of a protocol, not just a wish for a certain quality in your network. DTN has been around a while, seen real use, and is available for you to use, too.
Think about it. On Earth, a long ping time might be 400 ms, and most of that is in equipment, not physical distance. Add a geostationary orbital relay, and you get 600 ms to 800 ms. The moon? The delay is 1.3 sec. Mars? Somewhere between 3 min and 22 min, depending on how far away it is at the moment. Voyager 1? Nearly a two-day round trip. That’s latency!
When we first heard the term “random laser,” we did a double-take. After all, most ordinary sources of light are random. One defining characteristic of a traditional laser is that it emits coherent light. By coherent, in this context, that usually includes temporal coherence and spatial coherence. It is anything but random. It turns out, though, that random laser is a bit of a misnomer. The random part of the name refers to how the device generates the laser emission. It is true that random lasers may produce output that is not coherent over long time scales or between different emission points, but individually, the outputs are coherent. In other words, locally coherent, but not always globally so.
That is to say that a random laser might emit light from four different areas for a few brief moments. A particular emission will be coherent. But not all the areas may be coherent with respect to each other. The same thing happens over time. The output now may not be coherent with the output in a few seconds.
Baseline
A conventional laser works by forming a mirrored cavity, including a mirror that is only partially reflective. Pumping energy into the gain medium — the gas, semiconductor, or whatever — produces more photons that further stimulate emission. Only cavity modes that satisfy the design resonance conditions and experience gain persist, allowing them to escape through the partially reflecting mirror.
The laser generates many photons, but the cavity and gain medium favor only a narrow set of modes. This results in a beam that is of a very narrow band of frequencies, and the photons are highly collimated. Sure, they can spread over a long distance, but they don’t spread out in all directions like an ordinary light source. Continue reading “The Random Laser”→
