Wine has become a highly optimized and useful piece of software for those that live in Linux, but occasionally need to walk on the Windows side. In case you’d wondered, there’s a similar tool for when you need to run a MacOS program in your Linux environment. Enter Darling, the translation layer you’ve needed all along.
Just as Wine is not an emulator, nor is Darling. As a translation layer, it duplicates functions of the MacOS operating system that programs need to operate but within Linux. It’s fast, because it’s effectively running the MacOS software directly. Initially, Darling was mostly only capable of running MacOS apps at the console level. However, there is rudimentary support for running graphical applications that are based on the Cocoa framework.
Hilariously, if you’re into weird recursive situations, you can go deeper and run Darling within Windows Subsystem for Linux, itself running within Windows. Why? Well, you’re probably bored or just trying to for the sake of it. Regardless, we don’t judge. If you’ve got your own nifty translation or virtual machine hacks in the works, don’t hesitate to let us know!
Though Hackaday scribes have been known to imbibe a few glasses in their time, it’s fair to say that we are not a wine critic site. When a news piece floated by about a company getting into trouble for illegally submerging crates of wine though, our ears pricked up. Why are vintners dumping their products in the sea?
Making wine, or indeed any alcoholic beverage, starts with taking a base liquor, be it grape juice, apple juice, barley malt solution, or whatever, and fermenting it with a yeast culture to produce alcohol. The result is a drink that’s intoxicating but rough, and the magic that turns it into a connoisseur’s tipple happens subsequently as it matures. The environment in which the maturation happens has a huge influence on this, which is one of many reasons why wine from the cellar of a medieval chateau tastes better than that from an industrial unit in southern England. The Californian company was attempting to speed up this process by leaving the bottles beneath the waves. Continue reading “The Briny Depths Give Wine An Edge, But How?”→
Running applications on a different architecture than the one for which they were compiled is a common occurrence, not in the least with Apple’s architectural migration every decade or so. It’s also commonly used with for example ARM, OpenRISC, and RISC-V systems to run applications that are only available for x86 or x86_64. While QEMU and kin are often used here, they’re pretty resource heavy, which is where an option like Box86 and its 64-bit sibling Box64 are attractive options. Unlike QEMU, both offer dynamic recompilation and redirection of dynamic library calls to native libraries, including those for SDL and OpenGL.
Both are available on GitHub under an MIT license, with Box64 probably the most interesting these days as applications and games have moved on to a 64-bit only world. The only hard requirement that Box64 has for a host system is that it is little-endian, which is a pretty easy requirement to meet. The most recent release was on March 10th, with Box86 0.3 and Box64 0.2.2. As essentially a translation layer, it does not offer full compatibility with every bit of software out there, but it’s already good enough to run Steam, GoG, and Epic Game Store clients and install and run Windows games via Wine for x86.
A simple set of benchmarks comparing it with QEMU and FEX (another emulator) shows it to run both more applications, and with significantly better performance.
Good news for fans of PlayStation Vita — a new project from [Sergi “xerpi” Granell] allows users to run software written for Sony’s erstwhile handheld system on Nintendo’s latest money printing machine, the Switch. To be clear, there’s a very long road ahead before the vita2hos project is able to run commercial games (if ever). But it’s already able to run simple CPU-rendered Vita homebrew binaries on the Switch, demonstrating the concept is sound.
On a technical level, vita2hos is not unlike WINE, which enables POSIX-compliant operating systems such as Linux, Mac OS, and BSD to run Windows programs so long as they use the same processor architecture. Since the Switch’s ARM v8 processor is capable of executing code compiled for the Vita’s ARM v7 while running in 32-bit compatibility mode, there’s no emulation necessary. The project simply needs to provide the running program with work-alike routines fast enough, and nobody is the wiser. Of course, that’s a lot easier said than done.
According to the project page, the big hurdle right now is 3D graphics support. As you could imagine, many Vita games would have been pushing the system’s graphical hardware to the limit, making it exceptionally difficult to catch all the little edge cases that will undoubtedly come up when and if the project expands to support commercial titles. But for homebrew Vita games and utilities that may not even utilize the system’s 3D hardware, adding compatibility will be much easier. For instance, it’s already able to run [xerpi]’s own CHIP-8 emulator.
[xerpi] provides instructions on how to install vita2hos and the Vita executable to be tested onto an already hacked Nintendo Switch should you want to give it a shot. But unless you’ve got experience developing for the Vita or Switch and are willing to lend a hand, you might want to sit this one out until things mature a bit.
The news this week was dominated by the novel coronavirus outbreak centered in Wuhan, China. Despite draconian quarantines and international travel restrictions, the infection has spread far beyond China, at least in small numbers. A few cases have been reported in the United States, but the first case reported here caught our eye for the technology being used to treat it. CNN and others tell us that the traveler from Wuhan is being treated by a robot. While it sounds futuristic, the reality is a little less sci-fi than it seems. The device being used is an InTouch Vici, a telemedicine platform that in no way qualifies as a robot. The device is basically a standard telepresence platform that has to be wheeled into the patient suite so that providers can interact with the patient remotely. True, it protects whoever is using it from exposure, but someone still has to gown up and get in with the patient. We suppose it’s a step in the right direction, but we wish the popular press would stop slapping a “robot” label on things they don’t understand.
Also in health news, did you know you’re probably not as hot as you think you are? While a glance in the mirror would probably suffice to convince most of us of that fact, there’s now research that shows human body temperature isn’t what it used to be. Using medical records from the Civil War-era to the 1930s and comparing them to readings taken in the 1970s and another group between 2007 and 2017, a team at Stanford concluded that normal human body temperature in the USA has been slowly decreasing over time. They proposed several explanations as to why the old 98.6F (37C) value is more like 97.5F (36.4C) these days, the most interesting being that general overall inflammation has decreased as sanitation and food and water purity have increased, leading the body to turn down its thermostat, so to speak. Sadly, though, if the trend holds up, our body temperature will reach absolute zero in only 111,000 years.
Wine, the not-an-emulator that lets you run Windows programs on POSIX-compliant operating systems, announced stable release 5.0 this week. A year in the making, the new version’s big features are multi-monitor support with dynamic configuration changes and support for the Vulkan spec up to version 1.1.126.
Any color that you want, as long as it’s amorphous silicon. Sono Motors, the German start-up, has blown past its goal of raising 50 million euros in 50 days to crowdfund production of its Sion solar-electric car. The car is planned to have a 255 km range on a full charge, with 34 km of that coming from the solar cells that adorn almost every bit of the exterior on the vehicle. Living where the sun doesn’t shine for a third of the year, we’re not sure how well this will pay off, but it certainly seems smarter than covering roads with solar cells.
And finally, here’s a trip down memory lane for anyone who suffered through some of the cringe-worthy depictions of technology that Hollywood came up with during the 70s, 80s, and 90s. Looking back through the clips shown in “copy complete” reminds us just how many movies started getting into the tech scene. It wasn’t just the sci-fi and techno-thrillers that subjected us to closeups of scrolling random characters and a terminal that beeped every time something changed on the screen. Even straight dramas like Presumed Innocent and rom-coms like You’ve Got Mail and whatever the hell genre Ghost was got in on the act. To be fair, some depictions were pretty decent, especially given the realities of audience familiarity with tech before it became pervasive. And in any case, it was fun to just watch and remember when movies were a lot more watchable than they are today.
[BlueFlower] sends in this cool wine bottle engraver. It’s a simple machine that reminds us of the infamous EggBot. One axis can move in x and z while the other axis rotates the work piece. The EggBot works in spherical coordinates while this one lives in a cylindrical world.
The base of the device appears to be an older project of [BlueFlower]’s an XY-Plotter/Cutter. The plotter itself is a very standard twin-motor gantry design. In fact, it looks like when the machine is converted to bottle engraving, the drivers which previously moved the Y-axis are re-purposed to move two rollers. The rollers themselves are suspiciously similar to those found inside 2D printers. We all have them kicking around our junk drawers, but it’s rare to see them actually being used. The spindled is just a DC motor with a ball grinder coupled to the end.
As for the final result, we have to admit that the engraved bottles are quite fetching. Catch a video of the engraving process after the break.
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?
