In the surreal world of a pandemic lockdown, we are surrounded by news stories that defy satire. The idea that 5G cellular networks are to blame for the COVID-19 outbreak and a myriad other ills has the more paranoid corners of social media abuzz with concerned citizens leaping upon random pieces of street furniture as potential 5G infrastructure.
The unanimous advice of the world’s scientists, doctors, and engineers that it is inconceivable for a phone technology to cause a viral outbreak. Amusingly, 5G has not yet been rolled out to some of the places where this is happening. But with conspiracy theory, fact denial only serves to reinforce the idea, however misguided. Here at Hackaday we have already ventured into the technical and scientific side of the story, but there is another side to it that leaves the pandemic behind and reaches back over the decades. Fear of new technology and in particular radio is nothing new, it stretches back almost as long as the public has had access to it.
Another DDOS amplification technique has just recently been disclosed, NXNSAttack (technical paper here) that could be used against DNS servers.
We’ve covered amplification attacks before. The short explanation is that some UDP services, like DNS, can be abused to get more mileage out of a DDoS attack. The attacking machined send messages like this: “Hello Google DNS, This is the Hackaday server. Can you send me a really big DNS response packet?” If the DNS response is bigger than the request, then the overall attack is bigger as a result. The measure of effectiveness is the amplification factor. For every byte of DDoS sent by attacking machines, how much many bytes are actually sent to the victim machine? Mirai, for example, had an amplification factor of something around 2.6.
On Unix — the progenitor of Linux — there was /bin/sh. It was simple, by comparison to today’s shells, but it allowed you to enter commands and — most importantly — execute lists of commands. In fact, it was a simple programming language that could make decisions, loop, and do other things to allow you to write scripts that were more than just a list of programs to run. However, it wasn’t always the easiest thing to use, so in true Unix fashion, people started writing new shells. In this post, I want to point out a few shells other than the ubiquitous bash, which is one of the successors to the old sh program.
Since the 7th Edition of Unix, sh was actually the Bourne shell, named after its author, Stephen Bourne. It replaced the older Thompson shell written in 1971. That shell had some resemblance to a modern shell, but wasn’t really set up for scripting. It did have the standard syntax for redirection and piping, though. The PWB shell was also an early contender to replace Thompson, but all of those shells have pretty much disappeared.
You probably use bash and, honestly, you’ll probably continue to use bash after reading this post. But there are a few alternatives and for some people, they are worth considering. Also, there are a few special-purpose shells you may very well encounter even if your primary shell is bash.
If you haven’t heard from other websites yet, earlier this year a leak of various Nintendo intellectual properties surfaced on the Internet. This included prototype software dating back to the Game Boy, as well as Verilog files for systems up to the Nintendo 64, GameCube and Wii. This leak seems to have originated from a breach in the BroadOn servers, a small hardware company Nintendo had contracted to make, among other things, the China-only iQue Player.
So, that’s the gist of it out of the way, but what does it all mean? What is the iQue Player? Surely now that a company’s goodies are out in the open, enthusiasts can make use of it and improve their projects, right? Well, no. A lot of things prevent that, and there’s more than enough precedent for it that, to the emulation scene, this was just another Tuesday.
What is the right time to optimize code? This is a very good question, which usually comes down to two answers. The first answer is to have a good design for the code to begin with, because ‘optimization’ does not mean ‘fixing bad design decisions’. The second answer is that it should happen after the application has been sufficiently debugged and its developers are at risk of getting bored.
There should also be a goal for the optimization, based on what makes sense for the application. Does it need to process data faster? Should it send less data over the network or to disk? Shouldn’t one really have a look at that memory usage? And just what is going on inside those CPU caches that makes performance sometimes drop off a cliff on a single core?
All of this and more can be analyzed using tools from the Valgrind suite, including Cachegrind, Callgrind, DHAT and Massif.
Keeping Those Cores Cool
Modern day processors are designed with low power usage in mind, regardless of whether they are aimed at servers, desktop systems or embedded applications. This essentially means that they are in a low power state when not doing any work (idle loop), with some CPUs and microcontrollers turning off power to parts of the chip which are not being used. Consequently, the more the processor has to do, the more power it will use and the hotter it will get.
Because of the architecture used for the Apollo missions, extended stays on the surface of the Moon weren’t possible. The spartan Lunar Module simply wasn’t large enough to support excursions of more than a few days in length, and even that would be pushing the edge of the envelope. But then the Apollo program was never intended to be anything more than a proof of concept, to demonstrate that humans could make a controlled landing on the Moon and return to Earth safely. It was always assumed that more detailed explorations would happen on later missions with more advanced equipment and spacecraft.
Now NASA hopes that’s finally going to happen in the 2020s as part of its Artemis program. These missions won’t just be sightseeing trips, the agency says they’re returning with the goal of building a sustainable infrastructure on and around our nearest celestial neighbor. With a space station in lunar orbit and a permanent outpost on the surface, personnel could be regularly shuttled between the Earth and Moon similar to how crew rotations are currently handled on the International Space Station.
Artemis lander concept
Naturally, there are quite a few technical challenges that need to be addressed before that can happen. A major one is finding ways to safely and accurately deliver multiple payloads to the lunar surface. Building a Moon outpost will be a lot harder if all of its principle modules land several kilometers away from each other, so NASA is partnering with commercial companies to develop crew and cargo vehicles that are capable of high precision landings.
But bringing them down accurately is only half the problem. The Apollo Lunar Module is by far the largest and heaviest object that humanity has ever landed on another celestial body, but it’s absolutely dwarfed by some of the vehicles and components that NASA is considering for the Artemis program. There’s a very real concern that the powerful rocket engines required to gracefully lower these massive craft to the lunar surface might kick up a dangerous cloud of high-velocity dust and debris. In extreme cases, the lander could even find itself touching down at the bottom of a freshly dug crater.
Of course, the logical solution is to build hardened landing pads around the Artemis Base Camp that can support these heavyweight vehicles. But that leads to something of a “Chicken and Egg” problem: how do you build a suitable landing pad if you can’t transport large amounts of material to the surface in the first place? There are a few different approaches being considered to solve this problem, but certainly one of the most interesting among them is the idea proposed by Masten Space Systems. Their experimental technique would allow a rocket engine to literally build its own landing pad by spraying molten aluminum as it approaches the lunar surface.
While the car world is obsessed with everything boosted these days, many still yearn for the smooth power delivery and sonorous tone of a naturally aspirated engine. Of course, everyone still wants to go fast, so here’s how you go about getting more power out of your car without bolting on a big turbo or whining supercharger.
Intakes: This Can Get Pretty Invovled
A modified intake installed on a Honda S2000. Also referred to as “cold-air intakes”, they aim to suck in air at lower temperature which helps produce more power – hence the shield between the air filter and exhaust.
The intake is one of the first modifications made by many budding car enthusiasts. Throwing on a chromed intake pipe with a big pod filter was the mod to have back in the Fast and Furious era. Power gains can be had, though typically these are minor – on the order of 5-10 horsepower at most. It all depends on the car in question. A BMW M5 V10 was designed for high performance, with a highly advanced intake with individual throttle bodies from the factory. It’s unlikely any eBay parts are going to unlock horsepower that BMW’s engineers didn’t already find. Conversely, early Mazda Miatas are known to have a restrictive intake, largely due to the flap-type air flow meter. Replacing this with a freer-flowing setup has merit.
