Lightning is a powerful force, one seemingly capable of great destruction in the right circumstances. It announces itself with a searing flash, followed by a deep rumble heard for miles around.
Intuitively, it might seem like a lightning strike would be disastrous for something like a plane flying at altitude. And yet, while damage is possible, more often than not—a plane will get through a lightning storm unscathed. Let’s explore the physics at play.
Originally known as FORTRAN, but written in lower case since the 1990s with Fortran 90, this language was developed initially by John Backus as a way to make writing programs for the IBM 704 mainframe easier. The 704 was a 1954 mainframe with the honor of being the first mass-produced computer that supported hardware-based floating point calculations. This functionality opened it up to a whole new dimension of scientific computing, with use by Bell Labs, US national laboratories, NACA (later NASA), and many universities.
Much of this work involved turning equations for fluid dynamics and similar into programs that could be run on mainframes like the 704. This translating of formulas used to be done tediously in assembly languages before Backus’ Formula Translator (FORTRAN) was introduced to remove most of this tedium. With it, engineers and physicists could focus on doing their work and generating results rather than deal with the minutiae of assembly code. Decades later, this is still what Fortran is used for today, as a domain-specific language (DSL) for scientific computing and related fields.
In this introduction to Fortran 90 and its later updates we will be looking at what exactly it is that makes Fortran still such a good choice today, as well as how to get started with it.
The MOS Technology 6502 is a microprocessor which casts a long shadow over the world of computing. Many of you will know it as the beating heart of so many famous 8-bit machines from the likes of Commodore, Apple, Acorn, and more, and it has retained enough success for a version to remain in production today. It’s still a surprise though, to note that this part is now fifty years old. Though there are several contenders for its birthday, the first adverts for it were in print by July 1975, and the first customers bought their chips in September of that year. It’s thus only fitting that in August 2025, we give this processor a retrospective.
The Moment Motorola Never Really Recovered From
The advert that started it all. MOS Technology, Public domain.
The story of the 6502’s conception is a fascinating tale of how the giants of the early mocroprocessor industry set about grappling with these new machines. In the earlier half of the 1970s, Chuck Peddle worked for Motorola, whose 6800 microprocessor reached the market in 1974. The 6800 was for its time complex, expensive, and difficult to manufacture, and Peddle’s response to this was a far simpler device with a slimmed-down instruction set that his contact with customers had convinced him the market was looking for: the 6502.
There’s a tale of Motorola officially ordering him to stop working on this idea, something he would later assert as such an abandonment of the technology that he could claim the IP for himself. Accompanied by a group of his Motorola 6800 colleagues, in the summer of 1974 he jumped ship for MOS Technology to pursue the design. What first emerged was the 6501, a chip pin-compatible with the 6800, followed soon after by the 6502, with the same core, but with an on-board clock oscillator. Continue reading “Happy Birthday 6502”→
When all else fails, there’s amateur radio — and handwritten notes. Both ham radio and clear thinking helped rescue a mother and her son from a recent California camping trip gone wrong. While driving to the campsite in the Stanislaus National forest, the 49-year-old mother had the not-uncommon experience of GPS leading her and her 9-year-old son on a merry chase, sending her down a series of forest roads. Eventually the foliage got too dense for the GPS signals to penetrate, leaving the pair stranded in the forest with no guidance on how to get out.
BornHack is a week-long summer hacker camp in a forest on the Danish island of Fyn, that consistently delivers a very pleasant experience for those prepared to make the journey. This year’s version was the tenth iteration of the camp and it finished a week ago, and having returned exhausted and dried my camping gear after a Biblical rainstorm on the last day, it’s time to take a look at the badges. In case you are surprised by the plural, indeed, this event had not one badge but two. Last year’s badge suffered some logistical issues and arrived too late for the camp, so as a special treat it was there alongside the 2025 badge for holders of BornHack 2024 tickets. So without further ado, it’s time to open the pack for Hackaday and see what fun awaits us. Continue reading “Two For The Price Of One: BornHack 2024 And 2025 Badges”→
Another week, another Hackaday podcast, and for this one Elliot is joined by Jenny List, fresh from the BornHack hacker camp in Denmark.
There’s a definite metal working flavour to this week’s picks, with new and exciting CNC techniques and a selective electroplater that can transfer bitmaps to metal. But worry not, there’s plenty more to tease the ear, with one of the nicest cyberdecks we’ve ever seen, and a bird that can store images in its song.
Standout quick hacks are a synth that makes sounds from Ethernet packets, and the revelation that the original PlayStation is now old enough to need replacement motherboards. Finally we take a closer look at the huge effort that goes in to monitoring America’s high voltage power infrastructure, and some concerning privacy news from the UK. Have a listen!
Tea is a “dating safety” application strictly for women. To enforce this, creating an account requires an ID verification process where prospective users share their government issued photo IDs with the platform. And that brings us to the first Firebase leak. 59 GB of photo IDs and other photos for a large subset of users. This was not the only problem.
There was a second database discovered, and this one contains private messages between users. As one might imagine, given the topic matter of the app, many of these DMs contain sensitive details. This may not have been an unsecured Firebase database, but a separate problem where any API key could access any DM from any user.
This is the sort of security failing that is difficult for a company to recover from. And while it should be a lesson to users, not to trust their sensitive messages to closed-source apps with questionable security guarantees, history suggests that few will learn the lesson, and we’ll be covering yet another train-wreck of similar magnitude in another few months.
