Local Infrastructure: The Devil Is In The Details

About two months ago I rode my bike to work like any other day, but on the way home a construction project seemed to have spontaneously started at one of the bridges that I pass over. Three lanes had merged into one which, for a federal highway, seemed like a poorly planned traffic pattern for a such a major construction project. As it happens, about an hour after I biked across this bridge that morning both outside sections of the bridge fell into the water. There was no other physical damage that seemed to explain why parts of a bridge on U.S. 1 would suddenly collapse.

The intriguing thing about this bridge collapse was that the outer retaining wall and about half of the sidewalk on both the northbound side and the southbound side had fallen into the water at the same time. This likely wasn’t caused by something like a boat impact, car accident, or an overweight truck. Indeed, Florida Department of Transportation (FDOT) investigated the incident and found that two post tension wires that held these sections of the bridge together had failed, making it unsafe for pedestrians and bicyclists but also for any boaters below. Continue reading “Local Infrastructure: The Devil Is In The Details”

Meltdown Code Proves Concept

If you’ve read about Meltdown, you might have thought, “how likely is that to actually happen?” You can more easily judge for yourself by looking at the code available on GitHub. The Linux software is just proof of concept, but it both shows what could happen and — in a way — illustrates some of the difficulties in making this work. There are also two videos in the repository that show spying on password input and dumping physical memory.

The interesting thing is that there are a lot of things that will stop the demos from working. For example a slow CPU, a CPU without out-of-order execution, or an imprecise high-resolution timer. This is apparently especially problematic in virtual machines.

Continue reading “Meltdown Code Proves Concept”

You Got A 3D Printer, Now What?

Given the incredibly low prices on some of the models currently on the market, it’s more than likely a number of Hackaday readers have come out of the holiday season with a shiny new desktop 3D printer. It’s even possible some of you have already made the realization that 3D printing is a bit harder than you imagined. Sure the newer generation of 3D printers make it easier than ever, but it’s still not the same “click and forget” experience of printing on paper, for instance.

In light of this, I thought it might be nice to start off the new year with some advice for those who’ve suddenly found themselves lost in a forest of PLA. Some of this information may seem obvious to those of us who’ve spent years huddled over a print bed, but as with many technical pursuits, we tend to take for granted the knowledge gained from experience. For my own part, the challenges I faced years ago with my first wooden 3D printer were wholly different than what I imagined. I assumed that the real challenge would be getting the machine assembled and running, but the time it took to build the machine was nothing in comparison to the hours and hours of trial and error it took before I gained the confidence to really utilize the technology.

Of course, everyone’s experience is bound to be different, and we’d love to hear about yours in the comments. Grand successes, crushing defeats, and everything in between. It’s all part of the learning process, and all valuable information for those who are just starting out.

Continue reading “You Got A 3D Printer, Now What?”

PostMarketOS Saves Old Smartphones

Modern smartphones, even the budget models, are extremely impressive pieces of technology. Powerful ARM processors, plenty of RAM, and an incredible number of sensors and radios are packed into a device that in some cases are literally given away for free when you sign up for a service plan. Unfortunately manufacturers are not obligated to keep up with software updates, and while the hardware may be willing to keep on fighting, the user is often pushed to upgrade due to perennially outdated software. Even if you aren’t the kind of person to be put off by using a phone that doesn’t have the latest and greatest OS, the lack of software security updates pose a clear threat in a world where mobile devices are increasingly targeted by attackers.

But what if the operating system on your phone worked more like the on one your computer? That’s the dream of postmarketOS, a Linux distribution created by [Oliver Smith] that is designed to be installed on outdated (mostly Android) smartphones and tablets. He’s recently made a comprehensive blog post about the state of the project a little over 6 months since it started, and we have to say things are looking very impressive so far.

One of the key goals of postmarketOS is to avoid the fragmented nature of previous attempts at replacing Android with a community-developed operated system. By avoiding binary blobs and focusing on getting the mainline Linux kernel running on as much as the hardware as possible, there’s no need to make different forks and releases for each supported device. By unifying the OS as much as far as it can be, an upstream update can be pushed to all devices running postmarketOS regardless of their make and model, just like with traditional Linux distributions.

The blog post shows two things very clearly: that the community is extremely excited and dedicated to the prospect of running what is essentially desktop Linux on old smartphones and tablets, and that postmarketOS still has a long way to go. In these early days, many devices aren’t what could be considered “daily drivers” by most standards. In fact, the blog post mentions that they’ve decided to abandon the term “supported” when talking about devices, and make no claims beyond the fact that they will boot.

Still, incredible progress is being made on everything from mainline kernel development to getting standard Linux desktops such as Gnome, MATE and XFCE4 running. Work has also been done on the backend process of compiling and packaging up components of the operating system itself, promising to speed up development times even for those who don’t have a beefy machine they can dedicate to compiling. The blog post ends with a helpful list of things the reader can do to help support postmarketOS, ranging from making your own t-shirts to porting to new hardware.

At Hackaday we’ve seen our fair share of hackers and makers re-purposing old smartphones and tablets, keeping them out of the landfills they would almost certainly end up in otherwise. A project that aims to make it even easier to hack these cheap and incredibly useful devices is music to our ears.

Henrietta Lacks And Immortal Cell Lines

In early 1951, a woman named Henrietta Lacks visited the “colored ward” at Johns Hopkins hospital for a painful lump she found on her cervix. She was seen by Dr. Howard W. Jones, who indeed found a tumor growing on the surface of her cervix. He took a tissue sample, which confirmed Henrietta’s worst fears: She had cancer.

The treatment at the time was to irradiate the tumor with radium tubes placed in and around the cervix. The hope was that this would kill the cancerous cells while preserving the healthy tissue. Unbeknownst to Henrietta, a biopsy was taken during her radium procedure. Slivers of her tumor and of healthy cervix cells were cut away. The cancer cells were used as part of a research project. Then something amazing happened: the cancerous cells grew and continued to grow outside of her body.

As Henrietta herself lay dying, the HeLa immortal cell line was born. This cell line has been used in nearly every aspect of medical research since the polio vaccine. Millions owe their lives to it. Yet, Henrietta and her family never gave consent for any of this. Her family was not informed or compensated. In fact, until recently, they didn’t fully grasp exactly how Henrietta’s cells were being used.

Continue reading “Henrietta Lacks And Immortal Cell Lines”

Improved Perfboard For Surface Mount Parts

Look through the last two decades of electronics project built on perfboard, and you’ll notice a trend. Perfboard is designed for through-hole parts, but ever more frequently, the parts we need are only available as surface mount devices. What does this mean for the future of all those protoboard, veroboard, and tagboard designs? It’s not good, but fortunately, there may be an answer. It’s perfboard designed for mounting SOICs, SOTs, and other surface mount devices.

Perfboard is an extremely simple concept. Most through-hole electronic components are built around 0.1″ or 2.54 mm spacing between pins. Yes, there are exceptions, but you can always bend the middle pin of a transistor and put it in a hole. SMT devices are different. You can’t really bend the pins, and the pin pitch is too small for the 0.1″ holes in traditional perfboard.

[electronic_eel] is changing that game up with his own design for perfboard. This perfboard has the traditional 0.1″ holes, but there are SMD pads sprinkled about between these holes. The result is being able to solder SOIC, SOT23-6, SOT23 and SOT363 devices directly to a board alongside 0603 and 0805 devices. Connect everything with a few beads of solder and you have a functional circuit made out of surface mount devices on something that’s still compatible with the old protoboard designs.

This isn’t the first time we’ve seen a new type of protoboard make it into production. A few years ago, Perf+, a bizarre ‘bus-based’ protoboard solution came onto the scene, although that wasn’t really designed for SMD parts. While [electronic_eel] doesn’t have any plans to sell his protoboard, the files are available, and you can easily design your own small piece of perfboard.

Speculative Execution Was A Troublemaker For Xbox 360

Part of why people can’t stop talking about Meltdown/Spectre is the fact that all the individual pieces have been sitting in plain sight for a long time. When everyone saw how it all came together last week, many people (and not even necessarily security focused people) smacked themselves on the forehead: “Why didn’t I see that earlier?” Speculative execution has caused headaches going way back. [Bruce Dawson] tells one such story he experienced back in 2005. (Warning: ads on page may autoplay video.)

It’s centered around Xbox 360’s custom PowerPC processor. Among the customization on this chip was the addition of an instruction designed to improve memory performance. This instruction was a hack that violated some memory consistency guarantees held by the basic design, so they knew up front it had to be used very carefully. Even worse: debugging problems in this area were a pain. When memory consistency goes wrong, the code visible in the debugger might not be the actual code that crashed.

Since we’re talking about the dark side of speculative execution, you can already guess how the story ends: no matter how carefully it was used, the special instruction continued to cause problems when speculatively executed outside the constrained conditions. Extensive testing proved that instructions that were not being executed were causing crashes. That feels more like superstition than engineering. As far as he can recall, it ended up being more trouble than it was worth and was never used in any shipped Xbox 360 titles.

[Main image source: AnandTech article on Xbox 360 hardware]