The Saga Of 32-Bit Linux: Why Going 64-Bit Raises Concerns Over Multilib

July 9, 2019 by Tom Nardi 137 Comments

The story of Linux so far, as short as it may be in the grand scheme of things, is one of constant forward momentum. There’s always another feature to implement, an optimization to make, and of course, another device to support. With developer’s eyes always on the horizon ahead of them, it should come as no surprise to find that support for older hardware or protocols occasionally falls to the wayside. When maintaining antiquated code monopolizes developer time, or even directly conflicts with new code, a difficult decision needs to be made.

Of course, some decisions are easier to make than others. Back in 2012 when Linus Torvalds officially ended kernel support for legacy 386 processors, he famously closed the commit message with “Good riddance.” Maintaining support for such old hardware had been complicating things behind the scenes for years while offering very little practical benefit, so removing all that legacy code was like taking a weight off the developer’s shoulders.

The rationale was the same a few years ago when distributions like Arch Linux decided to drop support for 32-bit hardware entirely. Maintainers had noticed the drop-off in downloads for the 32-bit versions of their distributions and decided it didn’t make sense to keep producing them. In an era where even budget smartphones are shipping with 64-bit processors, many Linux distributions have at this point decided 32-bit CPUs weren’t worth their time.

Given this trend, you’d think Ubuntu announcing last month that they’d no longer be providing 32-bit versions of packages in their repository would hardly be newsworthy. But as it turns out, the threat of ending 32-bit packages caused the sort of uproar that we don’t traditionally see in the Linux community. But why?

Continue reading “The Saga Of 32-Bit Linux: Why Going 64-Bit Raises Concerns Over Multilib” →

Teardown: VeriFone MX 925CTLS Payment Terminal

July 8, 2019 by Tom Nardi 53 Comments

Regular Hackaday readers may recall that a little less than a year ago, I had the opportunity to explore a shuttered Toys “R” Us before the new owners gutted the building. Despite playing host to the customary fixture liquidation sale that takes place during the last death throes of such an establishment, this particular location was notable because of how much stuff was left behind. It was now the responsibility of the new owners to deal with all the detritus of a failed retail giant, from the security camera DVRs and point of sale systems to the boxes of employee medical records tucked away in a back office.

Clipping from New York Post. September 24th, 2018.

The resulting article and accompanying YouTube video were quite popular, and the revelation that employee information including copies of social security cards and driver’s licenses were left behind even secured Hackaday and yours truly a mention in the New York Post. As a result of the media attention, it was revealed that the management teams of several other stores were similarly derelict in their duty to properly dispose of Toys “R” Us equipment and documents.

Ironically, I too have been somewhat derelict in my duty to the good readers of Hackaday. I liberated several carloads worth of equipment from Geoffrey’s fallen castle with every intention of doing a series of teardowns on them, but it’s been nine months and I’ve got nothing to show for it. You could have a baby in that amount of time. Which, incidentally, I did. Perhaps that accounts for the reshuffling of priorities, but I don’t want to make excuses. You deserve better than that.

So without further ado, I present the first piece of hardware from my Toys “R” Us expedition: the VeriFone MX 925CTLS. This is a fairly modern payment terminal with all the bells and whistles you’d expect, such as support for NFC and EMV chip cards. There’s a good chance that you’ve seen one of these, or at least something very similar, while checking out at a retail chain. So if you’ve ever wondered what’s inside that machine that was swallowing up your debit card, let’s find out.

Continue reading “Teardown: VeriFone MX 925CTLS Payment Terminal” →

Five Years Of The Raspberry Pi Model B+ Form Factor, What Has It Taught Us?

July 8, 2019 by Jenny List 84 Comments

With all the hoopla surrounding the recent launch of the new Raspberry Pi 4, it’s easy to overlook another event in the Pi calendar. July will see the fifth anniversary of the launch of the Raspberry Pi Model B+ that ushered in a revised form factor. It’s familiar to us now, but at the time it was a huge change to a 40-pin expansion connector, four mounting holes, no composite video socket, and more carefully arranged interface connectors.

As the Pi 4 with its dual mini-HDMI connectors and reversed Ethernet and USB positions marks the first significant deviation from the standard set by the B+ and its successors, it’s worth taking a look at the success of the form factor and its wider impact. Is it still something that the Raspberry Pi designers can take in a new direction, or like so many standards before it has it passed from its originator to the collective ownership of the community of manufacturers that support it?

Continue reading “Five Years Of The Raspberry Pi Model B+ Form Factor, What Has It Taught Us?” →

Mary Sherman Morgan, Rocket Fuel Mixologist

July 2, 2019 by Kristina Panos 54 Comments

In the fall of 1957, it seemed as though the United States’ space program would never get off the ground. The USSR had launched Sputnik in October, and this cemented their place in history as the first nation in space. If that weren’t bad enough, they put Sputnik 2 into orbit a month later.

By Christmas, things looked even worse. The US had twice tried to launch Navy-designed Vanguard rockets, and both were spectacular failures. It was time to use their ace in the hole: the Redstone rocket, a direct descendant of the V-2s designed during WWII. The only problem was the propellant. It would never get the payload into orbit as-is.

The US Army awarded a contract to North American Aviation (NAA) to find a propellant that would do the job. But there was a catch: it was too late to make any changes to the engine’s design, so they had to work with big limitations. Oh, and the Army needed it two days before yesterday.

The Army sent a Colonel to NAA to deliver the contract, and to personally insist that they put their very best man on the job. And they did. What the Army didn’t count on was that NAA’s best man was actually a woman with no college degree.

Continue reading “Mary Sherman Morgan, Rocket Fuel Mixologist” →

Ask Hackaday: How Can You Build For A Ten Millennia Lifespan?

July 1, 2019 by Al Williams 97 Comments

There’s been a lot of news lately about the Long Now Foundation and Jeff Bezos spending $42 million or so on a giant mechanical clock that is supposed to run for 10,000 years. We aren’t sure we really agree that it is truly a 10,000 year clock because it draws energy — in part — from people visiting it. As far as we can tell, inventor Danny Hills has made the clock to hoard energy from several sources and occasionally chime when it has enough energy, so we aren’t sure how it truly sustains itself. However, it did lead us to an interesting question: how could you design something that really worked for 10,000 years?

Continue reading “Ask Hackaday: How Can You Build For A Ten Millennia Lifespan?” →

Reverse Engineering Cyclic Redundancy Codes

June 27, 2019 by Ted Yapo 17 Comments

Cyclic redundancy codes (CRC) are a type of checksum commonly used to detect errors in data transmission. For instance, every Ethernet packet that brought you the web page you’re reading now carried with it a frame check sequence that was calculated using a CRC algorithm. Any corrupted packets that failed the check were discarded, and the missing data was detected and re-sent by higher-level protocols. While Ethernet uses a particularly common CRC, there are many, many different possibilities. When you’re reverse-engineering a protocol that contains a CRC, although it’s not intended as a security mechanism, it can throw a wrench in your plans. Luckily, if you know the right tool, you can figure it out from just a few sample messages.

A case in point was discussed recently on the hackaday.io Hack Chat, where [Thomas Flayols] came for help reverse engineering the protocol for some RFID tags used for race timing. Let’s have a look at the CRC, how it is commonly used, and how you can reverse-engineer a protocol that includes one, using [Thomas’] application as an example.

Continue reading “Reverse Engineering Cyclic Redundancy Codes” →

What’s The Deal With Square Traces On PCBs

June 26, 2019 by Brian Benchoff 110 Comments

When designing a printed circuit board, there are certain rules. You should place decoupling capacitors near the power pins to each chip. Your ground planes should be one gigantic fill of copper; two ground planes connected by a single trace is better known as an antenna. Analog sections should be kept separate from digital sections, and if you’re dealing with high voltage, that section needs to be isolated.

One that I hear a lot is that you must never put a 90-degree angle on a trace. Some fear the mere sight of a 90-degree angle on a PCB tells everyone you don’t know what you’re doing. But is there is really no greater sin than a 90-degree trace on a circuit board?

This conventional wisdom of eschewing 90-degree traces is baked into everything we know about circuit board design. It is the first thing you’re taught, and it’s the first thing you’ll criticize when you find a board with 90-degree traces. Do square traces actually matter? The short answer is no, but there’s still a reason we don’t do it.

Continue reading “What’s The Deal With Square Traces On PCBs” →