While the Unix operating systems Solaris and HP-UX are still in active development, they’re not particularly popular anymore and are mostly relegated to some enterprise and data center environments They did enjoy a peak of popularity in the 90s during the “wild west” era of windowed operating systems, though. This was a time when there were more than two mass-market operating systems commercially available, with many companies fighting for market share. This led to a number of efforts to get software written for one operating system to run on others, whether that was simply porting software directly or using some compatibility layer. Surprisingly enough it was possible in this era to run an entire instance of Mac System 7 within either of these two Unix operating systems, and this was an officially supported piece of Apple software.
The software was called the Macintosh Application Environment (MAE), and was an effort by Apple to bring Macintosh System 7 applications to various Unix-based operating systems, including Solaris and HP-UX. This was a time before Apple’s OS was Unix-compliant, and MAE provided a compatibility layer that translated Macintosh system calls and application programming interfaces (APIs) into the equivalent Unix calls, allowing Mac software to function within the Unix environments. [Lunduke] outlines a lot of the features of this in his post, including some of the details the “scaffolding” allowing the 68k processor to be emulated efficiently on the hardware of the time, the contents of the user manual, and even the memory management and layout.
What’s really jarring to anyone only familiar with Apple’s modern “walled garden” approach is that this is an Apple-supported compatibility layer for another system. At the time, though, they weren’t the technology giant they are today and had to play by a different set of rules to stay viable. Quite the opposite, in fact: they almost went out of business in the mid-90s, so having their software run on as many machines as possible would have been a perk at the time. While this era did have major issues with cross-platform compatibility, there was some software that attempted to solve these problems that are still in active development today.
Originally designed since 2015 to propel the AARM mission to fetch rocks from an asteroid, when AARM was cancelled it became the cornerstone of the Lunar Gateway that should enable astronauts in the Artemis program to land on the Moon.
The AEPS is a solar electric propulsion system that uses xenon as its propellant, much like existing ion engines. Where it differs is in the power output, which should allow it to work as the primary propulsion method for large deep space and cargo missions. Much of the development and projections are covered in a 2017 presentation at the International Electric Propulsion Conference (IEPC).
Although the projected dates for much in this presentation (e.g. first flight of SLS Block 1 was in 2022, not 2018) are decidedly off, once the individual AEPS thrusters are validated, three strings will be mounted on the Power and Propulsion Element (PPE) that forms the core of the Lunar Gateway and is scheduled to be launched in November of 2025.
Top image: AEPS installed for testing at NASA Glenn. (Credit NASA)
After the Pi 4 released, a discovery was quickly made that the internals of the popular single-board computer use PCIe to communicate with each other. This wasn’t an accessible PCIe bus normally available in things like desktop computers for expansion cards, though; this seemed to be done entirely internally. But a few attempts were made to break out the PCIe capabilities and connect peripherals to it anyway, with varying levels of success. The new Pi 5 seems to have taken that idea to its logical conclusion and included a PCIe connector, and [George] is showing us a way to interface with this bus.
The bus requires the port to be enabled, but once that’s done it’s ready to be used. First, though, some support circuitry needs to be worked out which is why [George] is reverse engineering the system to see what’s going on under the hood. There are a few handshakes that happen before it will work with any peripherals, but with that out of the way a PCIe card can be connected. [George] removed the connector to solder wires to the board directly in order to connect a proper PCIe port allowing a variety of cards to be connected, in this case a wireless networking card and an old Firewire card. This specific build only allows Gen 1 speeds, but the bus itself supports faster connections in theory with better wiring and support circuitry.
While it might not be the prettiest solution, as [George] admits, it does a great job of showing the inner workings of this communication protocol and its use in the new, more powerful Raspberry Pi 5. This makes a lot of things more accessible, such as high-speed PCIe HATs allowing for a wide range of expansion for these popular single-board computers, which wouldn’t have been possible before. If you’re still stuck with a Pi 4, though, don’t despair. You can still access the PCIe bus on these older models but it’ll take a little bit more work.
DIY e-bikes are often easy to spot. If they’re not built out of something insane like an old washing machine motor, the more subtle kits that are generally used still stand out when compared to a non-assisted bike. The motors tend to be hub- or mid-drive systems with visible wires leading to a bulky battery, all of which stand out when you know what to look for. To get a stealthy ebike that looks basically the same as a standard bicycle is only possible with proprietary name-brand solutions that don’t lend themselves to owner repair or modification, but this one has at least been adapted for use with an open source motor controller.
The bike in use here is a model called the Curt from Estonian ebike builder Ampler, which is notable in that it looks indistinguishable from a regular bicycle with the exception of the small 36-volt, 350-watt hub motor somewhat hidden in the rear wheel. [BB8] decided based on no reason in particular to replace the proprietary motor controller with one based on VESC, an open-source electric motor controller for all kinds of motors even beyond ebikes. Installed on a tiny Arduino, it fits inside the bike’s downtube to keep the stealthy look and can get the bike comfortably up to around 35 kph. It’s also been programmed to turn on the bike’s lights if the pedals are spun backwards, and this method is also used to change the pedal assist level, meaning less buttons and other user-interface devices on the handlebars. Continue reading “An Open-Source Ebike Motor Controller”→
Collectively, we have a long-term memory problem. Paper turns to mulch, dyes in optical disks degrade, iron oxides don’t last forever, and flash memories will eventually fade away. So what do you do when you want to write something down and make sure it’s around a couple of thousand years from now? Easy — just use something that even Mother Nature herself has trouble breaking down: plastic.
Specifically, fluoropolymer fishing line, which is what [Nikolay Valentinovich Repnitskiy] uses as a medium in his “Carbon Record” project. There’s not a lot of information in the repository, but the basic idea is to encode characters by nicking the fishing line along its length. The encoder is simple enough; a spool of fresh line is fed into a machine where a solenoid drives a sharpened bolt against the filament. This leaves a series of nicks that encode the ones and zeros of 255 ASCII characters. It looks like [Nikolay] went through a couple of prototypes before settling on the solenoid; an earlier version used a brushed motor to drive the encoder, but the short, rapid movements proved too much for the motor to handle. We’ve included a video below that shows the device encoding some text; sounds a little like Morse to us.
There seems to be a lot more going on with this device than the repo lets on; we’d love to know what the big heat sink on top is doing, for instance. Hopefully we’ll get more details, including how [Nikolay] intends to decode the dents. Or perhaps that’s an exercise best left to whoever finds these messages a few millennia hence.
Since the very early 1990s, we have become used to ubiquitous digital mobile phone coverage for both voice and data. Such has been their success that they have for many users entirely supplanted the landline phone, and increasingly their voice functionality has become secondary to their provision of an always-on internet connection. With the 5G connections that are now the pinnacle of mobile connectivity we’re on the fourth generation of digital networks, with the earlier so-called “1G” networks using an analogue connection being the first. As consumers have over time migrated to the newer and faster mobile network standards then, the usage of the older versions has reduced to the point at which carriers are starting to turn them off. Those 2G networks from the 1990s and the 2000s-era 3G networks which supplanted them are now expensive to maintain, consuming energy and RF spectrum as they do, while generating precious little customer revenue.
Tech From When Any Phone That Wasn’t A Brick Was Cool
All this sounds like a natural progression of technology which might raise few concerns, in the same way that nobody really noticed the final demise of the old analogue systems. There should be little fuss at the 2G and 3G turn-off. But the success of these networks seems to in this case be their undoing, as despite their shutdown being on the cards now for years, there remain many devices still using them.
There can’t be many consumers still using an early-2000s Motorola Flip as their daily driver, but the proliferation of remotely connected IoT devices means that there are still many millions of 2G and 3G modems using those networks. This presents a major problem for network operators, utilities, and other industrial customers, and raises one or two questions here at Hackaday which we’re wondering whether our readers could shed some light on. Who is still using, or trying to use, 2G and 3G networks, why do they have to be turned off in the first place, and what if any alternatives are there when no 4G or 5G coverage is available? Continue reading “2G Or Not 2G, That Is The Question”→
Installing Linux on a modern PC has never been easier. There are tons of tools available that will nearly-automatically download your Linux distribution of choice, image a USB drive, and make it bootable so you can finally ditch your bloated, privacy-violating operating system and get the free performance boost that comes along with it. This wasn’t always the case, though. In the 90s you had to take a trip to a store (or library) and buy (or borrow) a boxed copy of some variety of Linux on floppy disk or CDs, and then install it on your own, often without the help of the Internet. [Action Retro] demonstrates this process for us so we don’t have to relive the pain ourselves.
Complete with a 90s-era Pentium machine enclosed in a beige case, this is really the full 90s experience. He’s found a boxed version of Red Hat version 5.2 with everything needed to get it up and running and, after a brief issue with the installer crashing because it couldn’t figure out the ZIP disk drive, had another era-appropriate experience by erasing the existing Windows 98 installation. This was before automatic partitioning tools were widely available, so it was a real risk for beginner Linux enthusiasts if they were trying to dual boot.
With the installation complete, the X window system still needed to be set up, as well as making sure the settings for the old CRT monitor were correct. With everything finalized, the system can really be explored. It includes out-of-the-box some software plenty of us would recognize today such as GIMP and some other software we might not, like Netscape Communicator. It’s a real time machine experience to get this operating system running on period-appropriate hardware, and a lot of features of modern Linux systems can still be seen especially if your modern distribution of choice still requires a lot of manual configuration during installation. Old operating systems aside, this machine might be capable of running a modern Linux distribution as well, provided it has something slightly newer than a 486.